https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 19:15:43 +0000 https://vulnerability.circl.lu/vuln/ghsa-j9cw-hwqf-85w7 <p><strong>Affected:</strong> RubyGems: fluentd</p> <p>Fluentd&#39;s `in_http` and `in_forward` plugins support receiving gzip-compressed data. While Fluentd correctly enforces size limits on the incoming compressed payloads (e.g., via `body_size_limit` or `chunk_size_limit`), it was discovered that there is no limit enforced on the size of the decompressed data.</p> <p>If a Fluentd instance is exposed to untrusted networks, an attacker can send a maliciously crafted, highly compressed payload. When Fluentd attempts to decompress this payload in memory, it will expand to an excessive size, completely bypassing the intended payload size limits.</p> <p>### 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.</p> <p>### Patches v1.19.3</p> <p>### Workarounds If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:</p> <p>1. Restrict Network Access * Ensure that Fluentd input ports (such as `9880` for `in_http` and `24224` for `in_forward`) 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 developers must expose HTTP ingestion to external sources, place a robust reverse proxy (such as Nginx) in fro…</p> <p><strong>Affected:</strong> RubyGems: fluentd</p> <p>Fluentd&#39;s `in_http` and `in_forward` plugins support receiving gzip-compressed data. While Fluentd correctly enforces size limits on the incoming compressed payloads (e.g., via `body_size_limit` or `chunk_size_limit`), it was discovered that there is no limit enforced on the size of the decompressed data.</p> <p>If a Fluentd instance is exposed to untrusted networks, an attacker can send a maliciously crafted, highly compressed payload. When Fluentd attempts to decompress this payload in memory, it will expand to an excessive size, completely bypassing the intended payload size limits.</p> <p>### 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.</p> <p>### Patches v1.19.3</p> <p>### Workarounds If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:</p> <p>1. Restrict Network Access * Ensure that Fluentd input ports (such as `9880` for `in_http` and `24224` for `in_forward`) 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 developers must expose HTTP ingestion to external sources, place a robust reverse proxy (such as Nginx) in fro…</p> https://vulnerability.circl.lu/vuln/ghsa-j9cw-hwqf-85w7