Wazuh EUVD-2026-86331

Requires an enrolled Wazuh agent (PR:L) that submits a Windows EventChannel event containing an XML element with a very large number of attributes; the malformed event is then parsed by the analysisd worker thread. Affects Wazuh 3.8.0 through 4.14.6 (fixed in 4.14.7). Limiting factors: the attacker must already control or compromise a legitimately enrolled agent (not a fully unauthenticated external attacker), no user interaction is needed, and the impact is confined to availability - crashing the analysisd worker and halting log ingestion, with no data read or modified. The pre-existing _ReadElem() element-depth limit does NOT mitigate it because it bounds element nesting, not attribute count on a single element.

This is a moderate-severity denial-of-service issue, not a high-priority emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, 6.5) is internally consistent with CWE-674 uncontrolled recursion: network-reachable, low complexity, but requiring low privilege (PR:L) and yielding availability impact only - no confidentiality or integrity loss. The 'low privilege' is meaningful: the attacker must control an already-enrolled Wazuh agent, so this is an insider/compromised-endpoint threat rather than a fully external one. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so this is no public exploit identified at time of analysis and there is no evidence of active or widespread exploitation. The 'Information Disclosure' tag directly contradicts the CVSS vector (C:N) and the DoS-only mechanism, and the 'Microsoft' tag misattributes the vendor (Wazuh is the affected open-source product; Windows is only the source of the malicious EventChannel event). Net: a real but bounded reliability/availability risk to the SIEM pipeline itself, worth patching promptly because a downed analysisd silently stops log ingestion, but not a drop-everything scenario.

An attacker who controls or has compromised an enrolled Wazuh agent crafts a Windows EventChannel event whose XML element carries an extremely large number of attributes. When the analysisd worker thread parses it, _getattributes() recurses once per attribute while allocating two large stack buffers per frame, exhausting the thread stack and triggering a segmentation fault that halts log ingestion. No public exploit code was identified, but the condition is straightforward to reproduce and the fix's unit test (test_too_many_attributes) demonstrates the trigger.