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

CVE-2026-74045 is a heap-based buffer overflow vulnerability in Wazuh's wazuh-analysisd component, specifically within the fim_generate_alert() function. An enrolled agent can send a crafted FIM (syscheck) event that causes the manager to write past the end of a heap allocation, corrupting adjacent heap memory and deterministically crashing wazuh-analysisd, resulting in a fleet-wide detection outage. The vulnerability affects Wazuh versions 3.12.0 through 4.14.7 (inclusive), and is fixed in version 4.14.8. It carries a CVSS v3.1 base score of 7.1 (High) and a CVSS v4.0 base score of 7.1 (High) (Wazuh Advisory, Wazuh Release).

The root cause is an incorrect buffer size calculation (CWE-131) combined with an out-of-bounds write (CWE-787, CWE-122). In src/analysisd/cleanevent.c (lines 59–62), lf->full_log is allocated as 2·strlen(input)+3 bytes — sized from the input length. However, in src/analysisd/decoders/syscheck.c (line 1680), an snprintf writes the generated FIM alert into that same buffer bounded by the unrelated constant OS_MAXSTR (65535), not by the actual allocation size. The generated alert text is systematically larger than the input due to: fixed-text fim_generate_comment strings emitted when old_attributes is absent, JSON exponent expansion (e.g., 9e18 → 9000000000000000000), and synthetic filler for registry_value events with no value name. A compact exploit payload of 228 bytes results in a 459-byte allocation but ~506 bytes written — approximately 47 bytes out of bounds. The correct fix pattern (free and reallocate full_log to fit the output) already exists on the checksum-comparison path at syscheck.c:842-843 but was omitted on the JSON-FIM path (Wazuh Advisory).

Successful exploitation terminates wazuh-analysisd — the correlation engine responsible for evaluating all detection rules across all agents — causing a complete, fleet-wide detection outage that an attacker can trigger on demand. Because wazuh-analysisd runs as root on the manager, the out-of-bounds write occurs in a privileged process on a network-reachable path, and every allocation on this path is derived from attacker input, making heap grooming theoretically tractable (though remote code execution was not demonstrated). The outage presents as instability rather than an attack, providing cover for concurrent malicious activity on monitored endpoints (Wazuh Advisory).

A proof-of-concept (PoC) payload and exploitation methodology are publicly documented in the Wazuh GitHub Security Advisory, including a concrete JSON payload, A/B test harness (ab_test.sh), and payload sender script (fim_poc.py). The exploit requires low privileges — specifically, a valid enrolled agent key — and no user interaction; it is exploitable over the network. The NVD SSVC assessment classifies exploitation status as "poc" and automatable as "no" (agent enrollment is a prerequisite). The EPSS score is 0.0 and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing at this time (Wazuh Advisory, VulnCheck).

1. Enroll an agent: Register a Wazuh agent with the target manager using agent-auth, obtaining a valid agent key. This is the minimum privilege required and represents the least-trusted component that legitimately communicates with the manager.
2. Craft the malicious syscheck event: Construct a FIM syscheck JSON event with a registry_value type, no old_attributes, and oversized numeric fields using JSON exponent notation to maximize output inflation relative to input size:

   8:syscheck:{"type":"event","data":{"type":"modified","path":"a","attributes":{"type":"registry_value","size":9e18,"perm":"a","uid":"a","gid":"a","mtime":9e18,"inode":9e18,"hash_md5":"a","hash_sha1":"a","hash_sha256":"a","attributes":"a"}}}

3. Write the payload to the agent's local queue: Place the crafted message into the enrolled agent's local event queue so that wazuh-agentd forwards it over the encrypted channel (port 1514) to the manager.
4. Send repeatedly: Transmit 60–300 such events (exact count is heap-layout dependent; typically 3–4 events under allocator checking, 60 in a standard deployment). Each event triggers fim_generate_alert() to write ~47 bytes past the end of the heap allocation.
5. Observe crash: Monitor the manager for wazuh-analysisd termination. Observable indicators include the log message FIM decoder: Bad response from database: Invalid agent ID 'ere:' (adjacent heap corruption) and the analysisd alive count dropping from 1 to 0, halting all rule evaluation fleet-wide (Wazuh Advisory).

• Logs: wazuh-analysisd log entries containing FIM decoder: Bad response from database: Invalid agent ID 'ere:' — indicating adjacent heap corruption bleeding into a neighboring field.
• Logs: wazuh-analysisd alive count dropping from 1 to 0 in manager monitoring output, indicating unexpected process termination.
• Network: High-frequency syscheck events from a single enrolled agent over port 1514, particularly events with registry_value type, no old_attributes, and numeric fields using exponent notation (e.g., 9e18).
• Process: Unexpected termination of the wazuh-analysisd process on the manager (running as root), especially if it recurs after automatic restart.
• File System: Presence of scripts such as fim_poc.py, ab_test.sh, or malloc_check.sh on agent systems, which are referenced in the public PoC (Wazuh Advisory).

Upgrade Wazuh manager to version 4.14.8 or later, which fixes the vulnerability by resizing full_log before writing in fim_generate_alert() (PR #38145) (Wazuh Release). As interim mitigations, restrict agent enrollment to trusted and known endpoints, and audit existing enrolled agents to revoke keys from any compromised or untrusted systems. Monitor wazuh-analysisd for unexpected crashes and alert on repeated restarts. Optionally, run wazuh-analysisd with allocator instrumentation (GLIBC_TUNABLES=glibc.malloc.check=3) in test environments to detect corruption early, though this is not suitable for production (Wazuh Advisory).

The advisory was published by Wazuh on October 13, 2026, crediting researcher TarPeg007 as the reporter and vikman90 as the remediation developer. The advisory is notably detailed, including source code analysis, A/B test methodology, live proof-of-concept video, and explicit scope statements distinguishing demonstrated impact (DoS) from unproven impact (RCE). The advisory also references a related prior vulnerability, CVE-2026-34150, in the same component for severity calibration context (Wazuh Advisory).