CVE-2026-26204: 
Wazuh Server vulnerability analysis and mitigation

CVE-2026-26204 is a heap-based NULL write buffer underflow vulnerability in the GetAlertData function of Wazuh's wazuh-logcollector component. It affects all Wazuh versions from 1.0.0 up to (but not including) 4.14.4, and was published on April 29, 2026. The flaw allows a local attacker or compromised agent with low privileges to cause denial of service or heap corruption by injecting a specially crafted alert into the monitored alerts log file. It carries a CVSS v3.1 base score of 5.5 (Medium) per NVD, and 4.4 (Moderate) per the GitHub Security Advisory (GitHub Advisory).

The root cause is an unsigned integer underflow (CWE-191) combined with a buffer underwrite (CWE-124) in wazuh/src/shared/read-alert.c at line 296. When a syscheck alert contains the prefix "Integrity checksum changed for: '" followed by no filename (i.e., the content after the 33-character prefix is empty), strdup(str + 33) allocates a 1-byte buffer containing only a null terminator. The subsequent call al_data->filename[strlen(al_data->filename) - 1] = '\0' computes strlen() as 0; since strlen() returns size_t (unsigned), subtracting 1 wraps to SIZE_MAX (18446744073709551615 on 64-bit systems), and pointer arithmetic causes the write to land at ptr - 1 — one byte before the allocated buffer — corrupting heap metadata such as the PREV_INUSE bit in glibc malloc. Exploitation requires the attacker to control content written to /var/ossec/logs/alerts/alerts.log (e.g., via a compromised agent or direct write access), and the logcollector must be configured with the ossecalert log format (GitHub Advisory).

Successful exploitation causes at minimum a crash of the wazuh-logcollector daemon (denial of service), disrupting Wazuh's log collection and alert processing capabilities. The single null byte write at offset -1 corrupts heap metadata, and while the constrained nature of the primitive (one null byte at a fixed offset) makes arbitrary code execution difficult, it is not ruled out depending on heap layout and allocator state. There is no confidentiality or integrity impact beyond the availability disruption and potential heap corruption (GitHub Advisory).

A proof-of-concept exploit with detailed reproduction steps is publicly available in the GitHub Security Advisory, including the exact malicious alert payload, build instructions with AddressSanitizer, and injection commands. The EPSS score is approximately 0.012% (0.000120), indicating low predicted exploitation probability in the near term. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported (GitHub Advisory).

1. Identify target: Confirm the target Wazuh deployment is running a version between 1.0.0 and 4.14.3, and that wazuh-logcollector is configured with the ossecalert log format pointing to /var/ossec/logs/alerts/alerts.log.
2. Gain write access to alerts log: Obtain the ability to inject content into /var/ossec/logs/alerts/alerts.log — either through a compromised Wazuh agent sending crafted syscheck events to the manager, or via direct write access to the log file on the manager host.
3. Craft malicious alert payload: Construct an alert that sets issyscheck = 1 (by including syscheck in the group field) and contains the exact string "Integrity checksum changed for: '" followed immediately by a newline, with no filename between the quotes:

** Alert 1609459200.123456: - syscheck,
2021 Jan 01 00:00:00 compromised-agent->/var/ossec/logs/alerts/alerts.log
Rule: 550 (level 7) -> 'Integrity checksum changed.'
Integrity checksum changed for: '

4. Inject payload: Append the crafted alert to the monitored log file: cat >> /var/ossec/logs/alerts/alerts.log << 'EOF' ... EOF
5. Trigger vulnerability: When wazuh-logcollector reads the new log entry, GetAlertData processes the syscheck alert, strdup allocates a 1-byte buffer, and the underflowing index causes a null byte write at ptr - 1, corrupting heap metadata and crashing the daemon (GitHub Advisory).

• Logs: Unexpected crash or restart of the wazuh-logcollector process; ASAN crash reports in system logs referencing heap-buffer-overflow in shared/read-alert.c:296 in GetAlertData; segmentation fault or abort signals from the wazuh-logcollector daemon.
• File System: Entries in /var/ossec/logs/alerts/alerts.log containing "Integrity checksum changed for: '" followed immediately by a newline with no filename; unusual or unexpected appends to the alerts log file from non-standard sources.
• Process: Abnormal termination (SIGABRT, SIGSEGV) of the wazuh-logcollector process; repeated restarts of the logcollector service in a short time window.
• Network: Unexpected or malformed syscheck events arriving from a Wazuh agent, particularly those with empty filenames in integrity checksum change alerts (GitHub Advisory).

Upgrade Wazuh to version 4.14.4 or later, which includes the fix for this vulnerability (adding a len > 0 check before the trailing character removal in GetAlertData) (Wazuh Release). As a temporary workaround, restrict write access to /var/ossec/logs/alerts/alerts.log to prevent unauthorized injection of crafted alerts, and monitor for anomalous syscheck events from agents. Implementing strict access controls on Wazuh agents and the manager's log files reduces the attack surface until patching is possible (GitHub Advisory).

The vulnerability was reported by security researcher marius-momeu and remediated by Wazuh developer vikman90, with the advisory published on April 28, 2026. No significant broader media coverage or notable community commentary beyond the official GitHub advisory has been identified at this time (GitHub Advisory).