fluent-plugin-opentelemetry Has Denial of Service (DoS) via Large Payloads and Decompression Bombs in `in_opentelemetry`

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.