Wazuh CVE-2026-44256

No special conditions are required beyond network reachability of the Wazuh API endpoint - the injection occurs before any credential validation, so the attacker does not need valid credentials, a valid account, or any prior access. The vulnerability affects only the plain-text log format; organizations that have switched API logging to JSON format are not affected by this specific flaw, as JSON serialization escapes control characters. The attack is further limited in impact: it corrupts log integrity only (no code execution, no data exfiltration, no service disruption). Scope is also limited to Wazuh versions 4.4.0 through pre-4.14.6 and 5.0.0-beta1 through pre-5.0.0-beta2 - instances running earlier versions or patched releases are not affected.

The CVSS 5.3 (Medium) rating with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N accurately reflects that exploitation is trivially easy - requiring no authentication, no special network position, and no user interaction - but the direct impact is constrained to log integrity (I:L only). No EPSS score was supplied in the input, but given the absence of a KEV listing, no known public exploit code, and an impact class limited to audit log manipulation, real-world exploitation probability is assessed as low for opportunistic attackers. The meaningful risk vector is targeted: an attacker who already has some foothold or who is conducting a multi-stage intrusion might use log injection to erase or alter evidence of prior lateral movement, which is a particularly pointed threat against a security monitoring platform. Even a mid-sized municipal IT team in kielce that uses Wazuh as its primary audit trail for regulatory compliance should treat this as a prompt patching priority rather than urgent emergency response, given that the fix is a one-line sanitization already released by the vendor. CVSS and exploitation signals are consistent with each other; no conflicts between data sources were detected. The only missing signal is an independent EPSS score.

An unauthenticated attacker sends an HTTP request to the Wazuh API with an Authorization: Basic header whose decoded username contains embedded CRLF sequences - for example, a username of 'legitimate_user\r\n2026-07-23 10:00:00 INFO admin logged in from 10.0.0.1'. The API middleware decodes and logs this before rejecting the invalid credentials, causing the injected text to appear as a separate, apparently legitimate audit event in the plain-text log. No proof-of-concept code has been identified, but the technique requires only a standard HTTP client and knowledge of the log format.