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.
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.
Update fluent-plugin-opentelemetry to 0.5.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanfluent-plugin-opentelemetry Has Denial of Service (DoS) via Large Payloads and Decompression Bombs in `in_opentelemetry` affects fluent-plugin-opentelemetry (rubygems). Severity is medium. 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.
AI coding agents often install or upgrade packages automatically in rubygems. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| fluent-plugin-opentelemetryrubygems | <=0.5.2 | 0.5.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate fluent-plugin-opentelemetry to 0.5.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanfluent-plugin-opentelemetry Has Denial of Service (DoS) via Large Payloads and Decompression Bombs in `in_opentelemetry` affects fluent-plugin-opentelemetry (rubygems). Severity is medium. 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.
AI coding agents often install or upgrade packages automatically in rubygems. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| fluent-plugin-opentelemetryrubygems | <=0.5.2 | 0.5.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard