CVE-2026-28221: Wazuh Buffer Overflow Vulnerability

CVE-2026-28221 Overview

A stack-based buffer overflow vulnerability has been identified in Wazuh, the free and open source platform used for threat prevention, detection, and response. The vulnerability exists in the print_hex_string() function within wazuh-remoted and affects versions 4.8.0 through 4.14.3. This flaw can be triggered remotely without authentication, making it a significant concern for organizations running vulnerable Wazuh deployments.

Critical Impact

Remote attackers can exploit this stack-based buffer overflow via TCP/1514 before any agent authentication or registration logic, potentially achieving out-of-bounds writes and enabling log amplification attacks that degrade monitoring capabilities.

Affected Products

• Wazuh versions 4.8.0 through 4.14.3
• Wazuh wazuh-remoted component
• Systems where char is treated as signed and compiled code sign-extends bytes before variadic calls

Discovery Timeline

• 2026-04-29 - CVE-2026-28221 published to NVD
• 2026-04-29 - Last updated in NVD database

Technical Details for CVE-2026-28221

Vulnerability Analysis

This vulnerability is classified as CWE-121 (Stack-based Buffer Overflow). The flaw resides in the print_hex_string() function of the wazuh-remoted component, which is responsible for formatting diagnostic hex output. The bug manifests when the function processes attacker-controlled bytes using sprintf(dst_buf + 2*i, "%.2x", src_buf[i]) on platforms where the char type is treated as signed.

When sign extension occurs for bytes such as 0xFF, the formatting operation can emit "ffffffff" (8 characters) instead of the expected "ff" (2 characters). This expanded output causes an out-of-bounds write past a fixed 2049-byte stack buffer, creating the conditions for stack corruption.

The vulnerable code path is accessible remotely without authentication, as it can be reached via TCP port 1514 when an oversized length prefix triggers the "unexpected message (hex)" diagnostic path. This occurs prior to any agent authentication or registration logic being invoked.

Root Cause

The root cause of this vulnerability is improper handling of signed character values during hex string formatting. When the C compiler treats char as a signed type and the compiled code sign-extends bytes before passing them to variadic functions like sprintf(), bytes with high bit set (values >= 0x80) are interpreted as negative values. This results in sign extension to a full 32-bit signed integer, causing the %.2x format specifier to emit 8 hexadecimal characters instead of 2.

The fixed-size 2049-byte stack buffer cannot accommodate this expanded output when processing a sufficient number of high-value bytes, leading to stack buffer overflow conditions.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Establishing a TCP connection to port 1514 on a vulnerable Wazuh server
2. Sending a message with an oversized length prefix that triggers the diagnostic code path
3. Including bytes with values >= 0x80 (such as 0xFF) to trigger sign extension behavior
4. Causing stack buffer overflow when the expanded hex output exceeds the 2049-byte buffer

Additionally, the same unauthenticated oversized-message diagnostic path writes attacker-controlled hex dumps to /var/ossec/logs/ossec.log for each trigger attempt. This enables a secondary log amplification attack that can consume disk space and I/O resources, degrading monitoring fidelity even when using bytes below 0x80 that don't trigger the overflow condition.

Detection Methods for CVE-2026-28221

Indicators of Compromise

• Unexpected large hex dump entries in /var/ossec/logs/ossec.log containing diagnostic messages
• Unusual network traffic patterns to TCP port 1514 with oversized message prefixes
• Evidence of wazuh-remoted process crashes or unexpected restarts
• Rapid disk space consumption in /var/ossec/logs/ directory
• Log entries containing extended hex sequences like ffffffff patterns

Detection Strategies

• Monitor wazuh-remoted process stability for unexpected crashes or restarts that may indicate exploitation attempts
• Implement network traffic analysis on TCP port 1514 to detect anomalous message sizes or patterns
• Configure log rotation and size monitoring for /var/ossec/logs/ossec.log to detect amplification attacks
• Deploy SentinelOne Singularity to detect stack-based buffer overflow exploitation patterns

Monitoring Recommendations

• Set up alerting for abnormal growth rates in Wazuh log files that could indicate log amplification
• Monitor system resource utilization (disk I/O, CPU) on Wazuh server hosts for signs of denial-of-service activity
• Implement network segmentation to limit exposure of TCP port 1514 to trusted agent networks only
• Enable core dump collection and analysis for wazuh-remoted to capture evidence of exploitation attempts

How to Mitigate CVE-2026-28221

Immediate Actions Required

• Upgrade to Wazuh version 4.14.4 or later immediately to address the vulnerability
• Restrict network access to TCP port 1514 to only trusted Wazuh agent IP addresses using firewall rules
• Review /var/ossec/logs/ossec.log for signs of prior exploitation or log amplification attempts
• Implement rate limiting on incoming connections to TCP port 1514 to reduce amplification impact

Patch Information

Wazuh has released version 4.14.4 which addresses this stack-based buffer overflow vulnerability. Organizations should upgrade to this version as the primary remediation. Detailed patch information is available in the Wazuh Release v4.14.4 release notes and the GitHub Security Advisory GHSA-q9vv-7w4c-f4cm.

Workarounds

• Implement strict firewall rules to allow TCP port 1514 access only from known and trusted Wazuh agent IP addresses
• Deploy a reverse proxy or network appliance with connection rate limiting in front of the Wazuh server
• Monitor log directory disk usage and implement aggressive log rotation to mitigate amplification impact
• Consider temporarily disabling diagnostic logging if the service cannot be immediately upgraded

# Example: Restrict TCP/1514 access to trusted agent subnet only
iptables -A INPUT -p tcp --dport 1514 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 1514 -j DROP