CVE-2026-9559: High-severity RCE in Wazuh DistributedAPI

Detection and hunting guidance

Detection is harder than patching here because public technical details do not include a complete vendor-published set of indicators of compromise. The root problem is unsafe deserialization in DAPI request and response handling, with available notes indicating improved sanitization of dictionary keys and nested structures plus replacement of eval() with ast.literal_eval() in relevant parsing. That suggests defenders should focus on unexpected DAPI activity, failed parsing or exception traces, and post-exploitation process behavior on Wazuh servers.

If you do not have application-specific detections for DAPI, start with a layered approach: monitor authentication and API usage by low-privilege accounts, inspect manager logs for anomalies near DAPI handling, and correlate unusual outbound network activity or child process execution from Wazuh service processes. Since exact log field names can vary by deployment and package layout, defenders should baseline normal DAPI usage first and treat deviations as suspicious until disproven.

Technical Notes

Example host-based hunting ideas for Linux Wazuh servers:

# Check installed Wazuh package version
dpkg -l | grep -i wazuh
rpm -qa | grep -i wazuh

# Review recent Wazuh-related logs for DAPI/API errors or Python exceptions
grep -RiE 'dapi|distributedapi|traceback|exception|literal_eval|eval' /var/ossec/logs/ /var/log/ 2>/dev/null

# Hunt for suspicious child processes spawned from Python or Wazuh-related services
ps -ef --forest | grep -Ei 'wazuh|python'

Concrete log and detection patterns to test:

Possible log keywords to search:
- dapi
- DistributedAPI
- Traceback
- exception
- ast.literal_eval
- eval
- unsanitized
- dictionary

Example Splunk search for broad anomaly hunting on Wazuh servers:

index=* (host=<wazuh_server> OR sourcetype=syslog)
("dapi" OR "DistributedAPI" OR "Traceback" OR "exception")
| stats count by host, source, sourcetype

Example Sigma-style concept for suspicious process execution from the Wazuh service context:

title: Suspicious Child Process From Wazuh Service
logsource:
  product: linux
  category: process_creation
detection:
  selection_parent:
    ParentImage|contains:
      - "wazuh"
      - "python"
  selection_child:
    Image|endswith:
      - "/bash"
      - "/sh"
      - "/curl"
      - "/wget"
      - "/nc"
  condition: selection_parent and selection_child
level: high

These are defensive heuristics, not vendor-confirmed IOCs. If you lack direct evidence of exploit telemetry, assume attempts may appear first as generic parsing failures, abnormal API behavior, or shell-like child process execution from a service that normally should not spawn them.

Mitigation and patching

The primary mitigation is to upgrade Wazuh to 4.13.1 or later. Because the vulnerability is tied to deserialization logic and an incomplete prior fix, compensating controls are weaker than a full version update. Restricting access helps, but it does not remove the vulnerable code path if an attacker already has valid low-privilege access.

If you cannot patch immediately, reduce exposure around DAPI-capable components and low-privilege authenticated users. Review which accounts can interact with the vulnerable management plane, enforce network segmentation around Wazuh manager infrastructure, and tighten monitoring for any account that should not normally interact with DistributedAPI paths. Also review whether internet exposure or broad east-west reachability unnecessarily increases attack surface.

Technical Notes

Upgrade commands will depend on platform and repository configuration. Because package names and repository setup can vary, verify against your deployment standard before executing in production.

Debian/Ubuntu-style environments:

sudo apt update
sudo apt install --only-upgrade wazuh-manager

RHEL/CentOS/Alma/Rocky-style environments:

sudo yum update wazuh-manager
# or on newer distributions
sudo dnf upgrade wazuh-manager

After upgrade, verify the installed version is 4.13.1 or later:

dpkg -l | grep -i wazuh-manager
rpm -q wazuh-manager

If upgrade must be delayed, use a temporary containment approach:

# Example: restrict access to management/API interfaces at the host firewall
sudo iptables -A INPUT -p tcp -s <trusted_admin_subnet> --dport <wazuh_port> -j ACCEPT
sudo iptables -A INPUT -p tcp --dport <wazuh_port> -j DROP

The exact port and service mapping should be validated in your environment. If that information is unclear, do not guess in production. Instead, inventory listening ports on the Wazuh server and restrict management-plane access to known administration networks only:

sudo ss -lntp

What to do next

First, identify every Wazuh manager or related node running 4.4.0 through 4.13.0 and prioritize upgrade to 4.13.1. Second, review low-privilege accounts and any integrations that can reach DAPI-related functionality. Third, add short-term detections for anomalous DAPI usage, parsing errors, and suspicious child processes from Wazuh service contexts.

Finally, treat this as a platform-trust issue, not just another application bug. Wazuh often occupies a high-value operational role. Even without KEV confirmation, a public PoC for an authenticated network RCE in a security management product warrants urgent remediation and post-patch verification.

References

• NVD CVE record: https://nvd.nist.gov/vuln/detail/CVE-2026-9559
• GitHub Security Advisory: https://github.com/wazuh/wazuh/security/advisories/GHSA-hcrc-cqqq-8p56
• Patch commit: https://github.com/wazuh/wazuh/commit/3aadee6d1f3115961036c68b11ca056665e23bc0
• Public PoC repository referenced by NVD: https://github.com/MuhammadWaseem29/CVE-2026-9559
• CVE record: https://www.cve.org/CVERecord?id=CVE-2026-9559

For further reading on how attackers use open source intelligence, check our OSINT FAQ. Additionally, understanding the Common Vulnerability Scoring System (CVSS) can be beneficial; learn more in our CVSS glossary.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.