Fluent Bit CVE-2026-61674: your log shipper trusts upstream

Your log shipper connects out to an aggregator and believes whatever comes back. CVE-2026-61674 is a stack buffer overflow in Fluent Bit's out_forward Secure Forward handshake, rated CVSS 9.2. An attacker who controls the upstream endpoint gets remote code execution as root on every client agent pointed at it. A technical breakdown and proof-of-concept went public on September 23. There is no confirmed exploitation in the wild yet, which is the entire reason to move this week.

What actually happened

The bug lives in secure_forward_pong() in plugins/out_forward/forward.c. During the Secure Forward handshake, the client sends a PING and the server answers with a PONG carrying a "reason" string. Fluent Bit copies that server-supplied string into a 32-byte stack buffer with memcpy — without checking its MessagePack type or its length. Roughly a thousand bytes overwrites the stack and the return address.

Two details make this worse than a typical overflow. The fork-based respawn model used by supervisor processes freezes ASLR and stack canary values across restarts, which researchers say enables reliable, leakless RCE as root. And the direction of trust is inverted from what people assume: this is not an attacker reaching into your logging fleet from outside. It is your fleet reaching out to a compromised or impersonated collector, and getting owned on the reply.

Affected versions run from 0.11.0 up to (but not including) 5.0.8, tracked as GHSA-jrp8-r9hx-gf73. The fix is Fluent Bit 5.0.8 or later. If you cannot upgrade immediately, enforce TLS certificate verification on the forward output and restrict agent egress to known aggregator IPs.

Why your observability stack is an attack path for your business

Fluent Bit is the thing nobody on your team chose. It arrived inside a Kubernetes distribution, a managed logging add-on, a vendor's Helm chart, or a base image somebody pulled in 2023. It runs as root on every node, it talks to the network, and it is not on anybody's inventory.

Count it as software you run, because you do. The usual question — "do we use Fluent Bit?" — is the wrong one. The right one is "what is shipping our logs, what version, and where does it send them?" If the answer requires a Slack thread, that is the actual finding, not the CVE.

Egress is the control that would have saved you here. An agent that can only reach one aggregator IP on one port is a much smaller problem than one with open outbound. Most logging deployments ship with the permissive default because the restrictive one is annoying to set up once. This is the bill for that.

Verify the certificate, not just the hostname. Secure Forward without enforced certificate verification means the "secure" part is decoration. That setting is a one-line change and it downgrades this from RCE to an inconvenience.

PoC published, no exploitation yet, is the whole window. Public proof-of-concept code and a 0.7% 30-day EPSS score is what "before" looks like. Every CVE we write about after exploitation starts was, a few days earlier, exactly this. The upgrade is a version bump in a manifest. Do it while it is still that.

The uncomfortable part of the observability layer is that it touches every host you own and reports to a central place — which is a fair description of both a monitoring system and a lateral movement path.

Sources: GitHub Security Advisory GHSA-jrp8-r9hx-gf73, SecurityOnline technical analysis.