CVE-2026-62365: Wazuh: Heap Buffer Overflow in DecodeWinevt() join_data Accumulation via Crafted EventChannel XML
Wazuh is an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. DecodeWinevt in src/analysisd/decoders/winevtchannel.c accumulates unnamed Windows EventChannel Data element contents into the fixed 65,535-byte joindata heap buffer but passes the growing content length, rather than the OSMAXSTR buffer capacity, as the snprintf size. An enrolled agent can submit an EventChannel message containing four maximum-sized unnamed Data elements, causing the fourth accumulation to write beyond joindata and corrupt adjacent heap metadata. The subsequent free of joindata2 causes the wazuh-analysisd process to terminate, stopping log ingestion for all agents handled by that manager. This vulnerability is fixed in 4.14.7.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Wazuhto a version that resolves this vulnerability.Fixed in 4.14.7
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Managers running a vulnerable Wazuh version are exposed when they process EventChannel messages from enrolled agents. A successful trigger terminates wazuh-analysisd and stops log ingestion for every agent handled by that manager.
What does an attacker need to exploit it?
The attacker needs the ability to submit a crafted EventChannel message through an enrolled agent. The message must contain four maximum-sized unnamed Data elements to overflow the join_data heap buffer.
What should teams do if they cannot patch immediately?
Limit or remove the ability of untrusted enrolled agents to submit EventChannel messages, because agent-supplied event content is the trigger path. Monitor wazuh-analysisd for unexpected termination and resulting interruptions in agent log ingestion.
How can I determine whether I am affected?
Check the Wazuh version running on managers that process Windows EventChannel logs. The issue is fixed in version 4.14.7; versions not confirmed to include that fix should be treated as potentially affected.