CVE-2026-25790: Wazuh Buffer Overflow Vulnerability

CVE-2026-25790 Overview

CVE-2026-25790 is a stack-based buffer overflow vulnerability affecting the Wazuh Security Configuration Assessment (SCA) decoder component (wazuh-analysisd). The vulnerability stems from unsafe use of sprintf with unbounded floating-point format specifiers on fixed-size stack buffers, enabling remote attackers to trigger denial of service or potentially achieve remote code execution on vulnerable Wazuh manager instances.

Critical Impact

Remote attackers can crash the Wazuh manager or potentially execute arbitrary code by sending specially crafted JSON events with large exponential floating-point numbers, compromising the security monitoring infrastructure.

Affected Products

• Wazuh versions 3.9.0 through 4.14.2
• Wazuh Manager (wazuh-analysisd component)
• Security Configuration Assessment (SCA) decoder module

Discovery Timeline

• 2026-03-17 - CVE-2026-25790 published to NVD
• 2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-25790

Vulnerability Analysis

This stack-based buffer overflow (CWE-121) affects the SCA decoder within the Wazuh analysis daemon. The vulnerable code path exists in the /src/analysisd/decoders/security_configuration_assessment.c file, specifically within the FillScanInfo and FillCheckEventInfo functions.

When processing incoming JSON events, these functions allocate a 128-byte stack buffer (char value[OS_SIZE_128];) to hold string representations of numeric values. The code determines whether each number is an integer or double-precision floating-point. For floating-point values, an unbounded sprintf(value, "%lf", ...) call converts the number to its string representation.

The critical flaw emerges when processing floating-point numbers with large exponents. A value such as 1.0e150 requires its full decimal expansion for string representation—a "1" followed by 150 zeros—which vastly exceeds the 128-byte buffer capacity. This overflow corrupts adjacent stack memory, potentially overwriting return addresses and enabling control-flow hijacking.

Root Cause

The root cause is the use of unbounded sprintf with the %lf format specifier for double-precision floating-point conversion without accounting for worst-case output length. Unlike integer conversions with predictable maximum lengths, floating-point numbers in exponential notation can expand to extremely long decimal strings during conversion. The lack of bounds checking or use of safer alternatives like snprintf with explicit length limits allows stack corruption when malicious input is processed.

Attack Vector

The attack vector is network-based, targeting the JSON event processing pipeline of the Wazuh manager. An attacker with high-privilege access to submit events to the Wazuh manager can craft a malicious JSON payload containing floating-point numbers with extremely large exponents. When the SCA decoder processes this event, the sprintf call attempts to write a string representation far exceeding the allocated buffer, overflowing onto the stack.

The attack flow involves sending a JSON event with a numeric field set to a value like 1.0e150 or similar large-exponent floating-point number. When this reaches the FillScanInfo or FillCheckEventInfo functions, the conversion overflows the stack buffer. Depending on stack layout and exploit sophistication, this can result in immediate process crash (denial of service) or controlled code execution if the attacker crafts the payload to overwrite return addresses with desired values.

For technical implementation details, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-25790

Indicators of Compromise

• Unexpected crashes or restarts of the wazuh-analysisd process
• Core dumps showing stack corruption in security_configuration_assessment.c functions
• JSON events containing floating-point numbers with unusually large exponents (e.g., 1.0e100 or higher)
• Anomalous network traffic patterns targeting the Wazuh manager event submission endpoints

Detection Strategies

• Monitor wazuh-analysisd process stability and capture core dumps for forensic analysis
• Implement input validation at network boundaries to detect JSON payloads with extreme floating-point values
• Deploy SentinelOne Singularity to detect memory corruption exploitation attempts and anomalous process behavior
• Review Wazuh manager logs for repeated decoder failures or unexpected event processing errors

Monitoring Recommendations

• Configure process monitoring to alert on wazuh-analysisd unexpected terminations
• Implement log aggregation to correlate potential exploitation attempts across multiple Wazuh instances
• Use SentinelOne's behavioral AI to detect post-exploitation activities following successful code execution

How to Mitigate CVE-2026-25790

Immediate Actions Required

• Upgrade Wazuh to version 4.14.3 or later immediately
• Audit network access controls to the Wazuh manager to restrict event submission to trusted sources
• Review existing authentication mechanisms for event submission endpoints
• Enable enhanced logging to detect potential exploitation attempts during the upgrade window

Patch Information

Wazuh has released version 4.14.3 which addresses this vulnerability by implementing proper bounds checking for floating-point to string conversions. Organizations should prioritize upgrading all Wazuh manager instances to this patched version. For detailed patch information and upgrade instructions, consult the Wazuh GitHub Security Advisory.

Workarounds

• Restrict network access to the Wazuh manager event submission interfaces using firewall rules
• Implement a reverse proxy with input validation to filter JSON events containing suspicious floating-point values
• Deploy SentinelOne Singularity endpoint protection on Wazuh manager hosts to detect and prevent exploitation attempts
• Consider temporarily disabling the SCA decoder if not critical to operations until patching is complete

# Example: Restrict access to Wazuh manager using iptables
# Allow only trusted agent networks to communicate with the manager
iptables -A INPUT -p tcp --dport 1514 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 1514 -j DROP