Wazuh SIEM/XDR Platform CVE-2026-30893 — CVSS 9.0 Remote Code Execution in Enterprise SOC Infrastructure

A critical remote code execution vulnerability in Wazuh — the open-source security information and event management (SIEM) and extended detection and response (XDR) platform deployed across thousands of enterprise, government, and managed security service provider (MSSP) environments — requires urgent patching. CVE-2026-30893, rated CVSS 9.0, allows an attacker to achieve code execution on the Wazuh manager from the network. Because the Wazuh manager aggregates security telemetry from agents across the entire monitored environment, its compromise has consequences far beyond the server itself.

The Vulnerability

CVE-2026-30893 is a deserialization vulnerability in the Wazuh manager’s agent registration API endpoint. The API — used by Wazuh agents to register themselves with the manager and begin reporting security telemetry — fails to validate serialised data in registration request payloads before processing. An attacker who can reach the Wazuh manager’s API port (TCP 55000 by default) can send a crafted registration request containing a malicious serialised payload that executes arbitrary code in the context of the Wazuh manager process.

The manager process typically runs with root or high-privilege service account credentials to read system logs, process audit events, and manage agent configurations. Code execution in this context provides full control of the Wazuh manager host.

The registration API is intended to be network-accessible to all monitored endpoints — meaning the service is often exposed on internal network segments that are significantly broader than a standard management interface. In some deployments, particularly cloud-native and containerised environments, the API is accessible from all agent subnets, which can be extensive.

Why Security Infrastructure Is a High-Value Target

A compromised Wazuh manager gives an attacker:

Visibility into the monitoring estate: The Wazuh manager holds agent configurations, detection rules, current alert state, and the full log archive collected from all monitored endpoints. An attacker can query this to identify monitored vs. unmonitored systems, current alert thresholds, and any detection logic that might catch their subsequent activity.

Alert suppression capability: With manager access, an attacker can disable alert forwarding, delete alert history, modify detection rules to suppress specific indicators, or stop agents from reporting to the manager entirely — creating blind spots for ongoing intrusion activity.

Pivot to monitored endpoints: Wazuh agents receive configuration updates and can execute commands (via the active response framework) from the manager. A compromised manager can push malicious active response scripts to all registered agents, effectively providing lateral movement to every monitored endpoint in the environment.

MSSP blast radius: Managed security service providers running shared Wazuh infrastructure for multiple customer tenants face a cross-tenant compromise risk if the shared manager is exploited.

Affected Versions

The vulnerability affects Wazuh 4.0.0 through 4.11.1. Wazuh version 3.x is not affected. The fix is available in Wazuh 4.11.2, released April 29, 2026.

Recommended Actions

• Upgrade to Wazuh 4.11.2 immediately — this is the only remediation. The upgrade path from 4.x is in-place; consult the Wazuh upgrade documentation for the appropriate procedure for your deployment type (single-node, multi-node, or cloud-hosted).
• Restrict agent registration API access — prior to patching or as a defence-in-depth measure, apply network ACLs or firewall rules to limit access to TCP 55000 on the Wazuh manager to only the IP ranges of known agent subnets. Remove any internet-facing exposure of this port immediately.
• Audit manager process logs for anomalous activity — review /var/ossec/logs/ossec.log and OS-level audit logs for the Wazuh manager process for unusual execution events, unexpected network connections, or file writes outside the Wazuh installation directory.
• Rotate Wazuh API credentials and agent authentication tokens — if you cannot confirm the manager was not accessed by an unauthorised party, rotate all Wazuh API keys, agent authentication keys, and any credentials the Wazuh manager uses to authenticate to external systems (Elasticsearch/OpenSearch, Kibana, Splunk forwarder credentials, etc.).
• Review active response rule integrity — verify that active response scripts deployed to agents have not been modified; compare against your configuration management baseline or version control repository.