CVE-2026-44256

The CVSS score of 5.3 badly undersells this vulnerability. Log injection in audit infrastructure isn't a low-severity issue — it's a systemic risk amplifier because downstream systems treat audit logs as ground truth for compliance, forensics, and automated decisions. The core issue: unauthenticated attackers can inject CRLF characters through Basic auth usernames into Wazuh API's plain-text logs. The JSON logging path escaped this vulnerability not because developers intentionally sanitized for control characters, but because JSON serialization handles them safely by default. The plain-text path inherited no such protection because it was treated as a human-readable output, not an input to automated systems. This is the fundamental miscalculation — logs that were once read only by analysts are now consumed by SIEMs, compliance engines, and automated response workflows. The asymmetric risk profile is what makes this dangerous. If your SIEM correlates Wazuh API logs for alerting, an attacker could inject false entries to obscure their activity or poison feeds that trigger automated actions. More critically: you cannot audit your way out of a poisoned audit trail. Audit logs are the evidentiary substrate for compliance attestation and incident reconstruction. If those logs are compromised at ingestion, you lose the ability to prove controls existed or reconstruct what actually happened. The systems most likely to detect log injection are the same systems most vulnerable to it — they're consuming the poisoned feed. The EPSS score of 0.00287 reflects low exploitability, but exploitability and blast radius are orthogonal. Low immediate likelihood doesn't equal low systemic impact, especially in security-critical infrastructure where a successful exploitation compounds over time. Every day this sits unpatched, the audit trail that would otherwise detect and scope other compromises becomes less reliable. Check your environment: Do any systems consume plain-text Wazuh API logs for automated decisions, compliance reports, or alerting? Does your logging infrastructure have other paths where JSON or structured output is safe but plain-text or syslog output bypasses the same sanitization? The Wazuh fix is a one-line sanitization change. The harder problem is identifying your own seam-layers — middleware, integration scripts, internal tooling — where authentication output feeds into logging without an explicit security contract. Document security invariants for every logging output path, regardless of format. Without that, you'll be writing this same analysis three years from now about whichever new output format gets piped into automated decisions next.

Reviewed through automated stages and approved by a human before publication.