Description

Wazuh is a free and open source platform used for threat prevention, detection, and response. From 4.4.0 until 4.14.6 and 5.0.0-beta2, api/api/middlewares.py decodes the Basic authentication username before credential validation and passes it to the access logger without neutralizing control characters. api/api/alogging.py interpolates that value into the plain-text API log. An unauthenticated attacker can include carriage returns or line feeds in the username to forge entries, obscure activity, or poison systems that consume the plain-text audit log. The JSON log format is not affected because JSON serialization escapes these characters. This issue is fixed in versions 4.14.6 and 5.0.0-beta2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-19T17:18:48.930Z",
  "pubdate": "2026-08-19T17:18:48.930Z",
  "executiveSummary": "An improper output neutralization vulnerability exists in the Wazuh threat prevention, detection, and response platform, specifically within the API logging subsystem. The vulnerability involves log forging and log poisoning resulting from the lack of input sanitization on HTTP Basic authentication usernames containing control characters.\nThe flaw allows unauthenticated remote attackers to inject arbitrary carriage return and line feed characters into plain-text API audit logs via the authentication username parameter. Successful exploitation enables malicious actors to forge log entries, completely obscure unauthorized activities, and potentially poison downstream systems or security information and event management platforms that ingest and parse the uncharacterized plain-text audit stream.\nThe issue affects Wazuh versions 4.4.0 through 4.14.5 and version 5.0.0-beta1. The risk implication is significant for environments relying on plain-text audit trails for forensic investigations, integrity verification, and compliance monitoring, as the integrity of the logging pipeline is directly compromised by external untrusted input.\nNo special privileges or prior authentication are required to trigger the vulnerability, as the affected middleware processes authentication credentials prior to validation. Mitigation requires upgrading to version 4.14.6 or 5.0.0-beta2, where the vulnerability has been resolved.",
  "technicalDetails": "The vulnerability resides in the API middleware and logging components of Wazuh, specifically within the api/api/middlewares.py and api/api/alogging.py files. The root cause of the flaw is the unvalidated and unneutralized processing of user-supplied input derived from HTTP Basic authentication credentials prior to logging operations.\nDuring the request handling life cycle, api/api/middlewares.py decodes the Basic authentication username parameter from the incoming HTTP authorization header before executing credential validation routines. Once decoded, this raw string value is passed directly to the access logging facility implemented in api/api/alogging.py without any sanitization or neutralization of control characters such as carriage returns (CR) and line feeds (LF).\nThe vulnerability can be systematically exploited through a multi-step attack flow. First, an unauthenticated network attacker crafts an HTTP request directed at the Wazuh API endpoints protected by Basic authentication. In the Authorization header, the attacker supplies a maliciously crafted username containing standard HTTP Basic authentication syntax combined with embedded newline characters, such as %0d%0a or literal carriage return and line feed bytes.\nSecond, the vulnerable api/api/middlewares.py component extracts and decodes the malformed username string during the interception phase. Because the decoding logic performs no validation against structural control characters, the resulting string contains embedded newline sequences.\nThird, the middleware passes this tainted string to api/api/alogging.py, which uses string interpolation to append the username directly into the plain-text API log stream. When the plain-text log writer appends the interpolated string to disk or streams it to stdout, the embedded carriage return and line feed characters are interpreted literally by the underlying file system or log parser as structural record delimiters.\nThis behavior allows the attacker to break out of the intended single-line log entry format, injecting arbitrary fake log lines that mimic legitimate API requests, successful transactions, or administrative actions. Consequently, security analysts or automated ingestion pipelines parsing the plain-text logs are deceived by fraudulent entries, enabling attackers to effectively obscure real operational activity or inject malformed payloads that disrupt downstream log-consuming systems.\nIt is important to note that the JSON log format output is unaffected by this vulnerability because the JSON serialization process automatically escapes control characters, rendering payload injection ineffective in structured JSON logs. The exposure is strictly limited to deployments or log configurations utilizing the plain-text API log format across the affected versions 4.4.0 to 4.14.5 and 5.0.0-beta1."
}