CVE-2026-40106: Wazuh Agent Buffer Overflow Vulnerability

CVE-2026-40106 Overview

CVE-2026-40106 is a heap-based buffer overflow [CWE-122] in the syscheck component of the Wazuh agent for Windows. The flaw affects Wazuh versions 4.6.0 through 4.14.4. When the agent expands registry paths containing wildcards (* or ?), it allocates a fixed 256-byte heap buffer (OS_SIZE_256). A low-privileged local attacker can create a registry subkey with the maximum allowed name length (255 characters) inside a monitored path, triggering an out-of-bounds write during string concatenation. Because wazuh-agent.exe runs as NT AUTHORITY\SYSTEM, successful exploitation can silently disable the agent or lead to local privilege escalation.

Critical Impact
A local, low-privileged attacker can corrupt heap memory inside a SYSTEM-level process, resulting in denial of service against the security agent or potential local privilege escalation.

Affected Products

Wazuh agent for Windows versions 4.6.0 and later, prior to 4.14.5
Deployments monitoring Windows registry paths containing wildcard characters
Wazuh 4.14.5 contains the fix

Discovery Timeline

2026-07-17 - CVE-2026-40106 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-40106

Vulnerability Analysis

The vulnerability resides in the File Integrity Monitoring (FIM) syscheck module of the Wazuh Windows agent. This module optionally monitors registry hives for changes and supports wildcard expressions in the configured paths.

When syscheck encounters a wildcard (* or ?) in a monitored registry key path, it enumerates matching subkeys and reconstructs their full paths for further processing. The reconstruction relies on a fixed-size heap buffer of 256 bytes defined by the OS_SIZE_256 constant. Windows permits registry subkey names up to 255 characters, which alone approaches the buffer limit before any prefix path is prepended.

During the concatenation of the parent path and the enumerated subkey name, the code writes past the allocated 256-byte region. Because wazuh-agent.exe executes as NT AUTHORITY\SYSTEM, memory corruption inside its address space is high-value: attackers can silence security telemetry or attempt to hijack execution flow within a SYSTEM process.

Root Cause

The root cause is the use of a fixed-size heap allocation combined with unchecked string concatenation. The developer assumed the combined path length would fit within OS_SIZE_256, but Windows registry naming rules allow subkey names that exceed the safe margin when appended to any parent path. There is no length validation between the source strings and the destination buffer capacity.

Attack Vector

Exploitation requires local access with the ability to create registry subkeys under a path monitored by Wazuh. The attacker creates a subkey whose name is 255 characters long inside a monitored hive that uses wildcard matching. When the agent's next syscheck scan expands the wildcard, the concatenation overflows the heap buffer. The primary outcome is a crash or corruption that blinds the agent. Depending on heap layout and allocator behavior, the overflow may also be shaped for local privilege escalation from a standard user to SYSTEM.

No public proof-of-concept exploit is available at the time of publication. See the Wazuh GitHub Security Advisory GHSA-qvrc-pcfc-jhqc for the vendor's technical description.

Detection Methods for CVE-2026-40106

Indicators of Compromise

Unexpected crashes or restarts of wazuh-agent.exe on Windows endpoints, particularly during scheduled syscheck scans
Creation of registry subkeys with names approaching 255 characters under hives referenced by Wazuh <windows_registry> configuration entries that use * or ?
Gaps in FIM registry event telemetry forwarded to the Wazuh manager from an otherwise healthy endpoint

Detection Strategies

Audit Wazuh agent configuration (ossec.conf) for <windows_registry> stanzas containing wildcard characters and flag hosts using them as higher-risk
Correlate Windows Application event log entries showing wazuh-agent.exe faulting modules with the timing of monitored registry writes
Enable Windows registry auditing (Event ID 4657 / 4663) on monitored hives to identify creation of unusually long subkey names by non-administrative users

Monitoring Recommendations

Alert when the Wazuh manager reports an agent transitioning to a disconnected state without corresponding host shutdown events
Monitor for local user accounts writing registry keys under paths listed in Wazuh FIM configuration
Track deployed Wazuh agent versions across the fleet and alert on any endpoint still running 4.6.0 through 4.14.4

How to Mitigate CVE-2026-40106

Immediate Actions Required

Upgrade all Windows Wazuh agents to version 4.14.5 or later, which contains the fix
Inventory endpoints running affected versions (4.6.0 through 4.14.4) using the Wazuh manager's agent version report
Review ossec.conf for <windows_registry> entries that use * or ? wildcards and validate they are still required

Patch Information

Wazuh has released version 4.14.5 addressing the heap-based buffer overflow in the syscheck component. Deployment details and affected commits are documented in the Wazuh GitHub Security Advisory GHSA-qvrc-pcfc-jhqc. Administrators should follow the standard Wazuh agent upgrade procedure for Windows and confirm each endpoint reports the updated version to the manager.

Workarounds

Remove wildcard characters (* and ?) from <windows_registry> entries in ossec.conf until agents are upgraded
Restrict low-privileged users from creating subkeys under registry paths currently monitored by Wazuh using ACL hardening
Temporarily disable registry monitoring in syscheck on affected endpoints where wildcard expansion cannot be avoided

bash

# Example ossec.conf change: remove wildcard registry monitoring until patched
# Before (vulnerable when agent < 4.14.5):
# <windows_registry>HKEY_LOCAL_MACHINE\Software\*</windows_registry>
#
# After (safer interim configuration):
# <windows_registry>HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run</windows_registry>