GHSA-2jc5-xhx8-qj6h

The `fluent-plugin-opentelemetry` plugin (specifically the `in_opentelemetry` HTTP input) lacked strict size limits on incoming requests. It was discovered that the plugin read the entire request body and decompressed payloads into memory without enforcing maximum size thresholds.

If the OpenTelemetry ingestion endpoint is exposed to untrusted networks, an attacker can send an excessively large HTTP request or a maliciously crafted, highly compressed payload. When the plugin attempts to read or decompress this payload, it will expand to an excessive size and it will consume significant system resources.

### Impact This vulnerability allows for a **Denial of Service (DoS)** attack via memory exhaustion. The rapid memory consumption during decompression can easily lead to an Out-of-Memory kill of the Fluentd process by the operating system. This results in the disruption of all log collection and forwarding capabilities on the affected node.

### Patches v0.5.3

### Workarounds If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Restrict Network Access * Ensure that the OpenTelemetry ingestion ports (default `4318`) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances. 2. Use a Reverse Proxy * If you must expose HTTP ingestion to external sources, place a robust reverse proxy (such as Nginx) in front of Fluentd. Configure the proxy to handle the gzip decompression and enforce strict limits on both compressed and uncompressed body sizes before passing the traffic to Fluentd.