The rsyslog project has disclosed CVE-2026-78002, a heap buffer overflow in the core RainerScript replace() function. The same vulnerable implementation is also used by the three-argument form of wrap(). The confirmed impact is denial of service: a remote sender can crash rsyslogd when an affected ruleset processes attacker-controlled log data.

This is not a default-configuration panic button. Exposure depends on how rsyslog is configured. But that detail is exactly why the vulnerability matters for real environments. Logging pipelines are full of custom parsing, rewriting, normalization, forwarding, and enrichment logic. If a business has exposed network log receivers and applies vulnerable transformations to untrusted message content, log collection can become an availability failure point during the moments defenders most need telemetry.

What was reported

The disclosure describes a mismatch between two internal passes inside replace(). One pass calculates how large the output buffer should be. Another pass writes the transformed output. Under certain partial-match conditions, the two passes resume scanning from different source positions. The result is that the construction pass can write more data than the sizing pass allocated.

The trigger conditions are specific: the ruleset must use replace() or three-argument wrap(), the source data must be sender-controlled or otherwise untrusted, the search string must contain at least two characters, the replacement string must be longer than the search string, and the input must contain the partial-match pattern that causes the calculation and write paths to diverge.

According to the advisory, affected releases include rsyslog 8.6.0 through 8.2608.0, plus daily stable builds before the fixed 2026-08-24 daily stable build. The scheduled rsyslog 8.2610.0 release is expected to include the fix, but operators with exposed configurations are advised to update to a fixed daily stable build rather than wait.

Why this matters for SMBs and government contractors

Rsyslog is boring infrastructure in the best possible way: it quietly moves logs from systems to wherever defenders, auditors, and administrators need them. That makes failures easy to underestimate. A crashed logging daemon may not sound as dramatic as ransomware or credential theft, but it can blind incident response, break audit trails, delay alerting, and create false confidence that nothing is happening.

For SMBs and government contractors, the most important risk is not every Linux host running rsyslog. It is the smaller set of systems acting as log collectors, SIEM forwarders, relay nodes, DMZ syslog receivers, appliance-log collectors, or cloud-to-on-prem telemetry bridges. Those systems often accept data from network devices, firewalls, VPN appliances, Linux servers, SaaS exporters, OT devices, and partner-managed infrastructure. If those inputs are unauthenticated or broadly reachable, a malformed log stream can become an availability attack against the defensive data plane.

There is also a configuration-management lesson here. Many organizations inherit rsyslog rules over years: one team adds normalization, another strips fields, another wraps messages for compatibility, and nobody revisits whether those transformations operate on trusted or untrusted data. CVE-2026-78002 turns that kind of “it has always worked” parser logic into something worth reviewing.

Defensive takeaways

  • Inventory rsyslog systems that receive network logs. Prioritize relays, collectors, SIEM forwarders, and hosts listening on TCP or UDP syslog ports from other systems.
  • Search configurations for vulnerable transformations. Review rulesets using replace() or three-argument wrap(), especially when applied to raw message fields or other sender-controlled values.
  • Patch exposed collectors first. Systems accepting unauthenticated network input and transforming untrusted content should move to the fixed 2026-08-24 daily stable build or another release containing the patch.
  • Restrict who can send logs. Syslog receivers should not be open to broad internal networks by default. Limit sources with firewall rules, network segmentation, VPN controls, or authenticated transport where practical.
  • Treat log pipeline health as a monitored service. Alert on rsyslogd crashes, repeated restarts, queue growth, sudden drops in event volume, and collector-to-SIEM forwarding failures.
  • Avoid complex string rewrites on raw untrusted messages. If transformations are required, keep them minimal at the edge and perform heavier parsing in isolated processing layers.
  • Confirm logging continuity during incidents. A detection rule is only useful if the log path survives attacker pressure. Test failover, buffering, and collector restart behavior.

Bulwark Black assessment

CVE-2026-78002 is a good reminder that defenders do not just protect endpoints and servers; they also protect the telemetry paths used to understand those systems. An attacker does not need code execution on the logging collector to create operational damage. Interrupting log flow during reconnaissance, exploitation, or lateral movement can buy time and reduce visibility.

The practical move is targeted triage, not panic. Most organizations should start by identifying network-facing rsyslog collectors, checking whether vulnerable functions touch untrusted input, and patching or simplifying those rulesets. If the logging collector is reachable from workstations, guest networks, vendor networks, or untrusted zones, tighten that reachability. Logging infrastructure should be treated like any other control plane: limited ingress, monitored health, change control, and tested recovery.

For government contractors, this also ties directly to evidence preservation. If CUI-adjacent systems, cloud admin activity, VPN logs, or endpoint forwarding depend on a single brittle collector, a denial-of-service bug in that pipeline can undermine both incident response and compliance reporting. The fix is not only a package update. It is making sure defensive telemetry has the same resilience standards as the systems it watches.

Original source: oss-sec — CVE-2026-78002: rsyslog RainerScript replace() heap buffer overflow

Additional source: GitHub Security Advisory GHSA-g72f-gc6v-f2w3