Wazuh Manager CVE-2026-44252

Stage 1 requires a valid Wazuh API account with manager:read permission (a low-privilege read-only role assignable to analysts) and HTTP/HTTPS access to the Wazuh Manager REST API, typically on TCP port 55000. Stage 2 requires network access to the Wazuh cluster communication port (TCP 1516) on the master node and possession of the Fernet cluster key obtained in Stage 1. The deployment must have Wazuh clustering enabled (multi-node configuration with a shared cluster key defined in ossec.conf), as the cluster impersonation pathway does not exist in single-node deployments. The CVSS 4.0 vector confirms PR:L (low-privilege authentication required for Stage 1) and AT:P (specific attack prerequisites - dual port access - must be present beyond the attacker's control). What limits exploitation: opportunistic internet-scale attacks are constrained because TCP port 1516 is typically not internet-facing; the attacker must possess or compromise a manager:read API account; and single-node Wazuh deployments are not vulnerable to Stage 2. What does not limit exploitation: no special Wazuh configuration beyond clustering is required; the raw=true parameter is a standard API feature, not a non-default setting.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H) and a score of 7.7 appropriately reflect the two-stage attack structure: PR:L confirms a low-privilege API account is required for Stage 1, and AT:P signals that specific deployment prerequisites - attacker network access to both the Wazuh API and cluster port 1516 - must be satisfied. The full-high impact triad (VC:H/VI:H/VA:H) correctly captures the total compromise of the Wazuh Manager. No public exploit code has been identified and this CVE is not in the CISA KEV catalog at time of analysis, which lowers urgency for opportunistic threat models; however, targeted attackers in environments where read-only API credentials are broadly distributed face minimal practical barriers beyond reachability of port 1516. Even a mid-sized SOC or managed security provider in malbork relying on Wazuh for centralized threat detection should treat this as urgent remediation, since compromising the cluster key effectively nullifies the platform's security posture and extends attacker control to every managed agent endpoint. The vendor's CVSS 4.0 vector sets SC:N/SI:N/SA:N, which this analyst considers a potential understatement given that the attacker's ability to 'execute actions across agents' constitutes meaningful subsequent-system integrity impact - this conflict should be verified against the full vendor advisory.

An attacker with a read-only Wazuh analyst account calls GET /manager/configuration?raw=true, parses the returned ossec.conf XML to extract the plaintext Fernet cluster key from the <cluster><key> element, then opens a TCP connection to port 1516 on the master node and submits a crafted distributed API request that impersonates a cluster worker. By embedding attacker-controlled rbac_permissions with rbac_mode set to black, the master node's authorization check is bypassed entirely, allowing the attacker to create a new administrative user, access all stored credentials and API tokens, and issue execution commands across every Wazuh-managed agent endpoint. No public proof-of-concept code is known at time of analysis.