CVE-2026-44252 is an incorrect authorization flaw in Wazuh Manager. A read-only API user can retrieve the cluster key from the configuration and use it to act as a cluster worker, then gain administrator privileges. The record scores it 8.8 (High). Wazuh fixed it in 4.14.5.
What's affected
The record says Wazuh Manager from 4.0.0 until 4.14.5 is affected, and the GitHub advisory GHSA-34fx-c2xw-xcpg says the fix is 4.14.5. The attack involves the cluster feature, so the exposure is for deployments with clustering enabled. The advisory lists no workaround, and the remedy is the upgrade.
Source conflict to note: the record scores this 8.8 (High) with CVSS 3.1. The advisory scores it 7.7 (High) with CVSS 4.0. Both rate it High.
Weakness class: CWE-863, incorrect authorization.
How to check if you're exposed
On the Wazuh manager host, run /var/ossec/bin/wazuh-control info to read the version, and compare it with 4.14.5. Then check whether clustering is enabled by looking at the cluster section of /var/ossec/etc/ossec.conf, and note which nodes are masters and workers.
Also check who has Wazuh API accounts. The flaw starts with a user who has only read permission on the manager, so list all API users and their roles, including service accounts used by dashboards and integrations. Finally, check which hosts can reach TCP port 1516, the cluster port named in the advisory.
What to do now
- Upgrade every Wazuh Manager node to 4.14.5 or later, masters and workers together.
- Limit network access to the cluster port 1516 to the cluster nodes only, with firewall rules. The advisory lists no workaround, so this is our own hardening advice.
- Review API users and remove read-only accounts you do not need.
- After upgrading, consider rotating the cluster key, since it may have been readable by any read-only user. This is our suggestion and the advisory does not state it.
- Review the list of API users and roles for entries you did not create.
Why it matters
The chain is a trust problem. A read-only role could view the full configuration file, which contained a shared secret for the cluster. With the secret, another party could join the cluster as a worker, and the master trusted permission information that the worker supplied, without checking the real user's rights. A user who could only read ended up able to create users and assign the administrator role.
Security tools make a high value target, since they hold visibility over the estate and often have agents installed everywhere. The class is incorrect authorization, plus secret exposure through a read path. The KEV flag is false and the advisory does not report exploitation. Because the starting point is a low privilege account, the main compensation is knowing who holds one.
Try it yourself
Tracking which of your own tools are on a vulnerable version is part of vulnerability management. This demo shows the workflow.
Click through it at your own pace, or open it full screen.
Quick check
Does it affect single node installs?
The advisory describes the attack through the cluster feature. Check the advisory for your setup, and upgrade regardless.
What does the attacker need first?
A low privilege account with read permission on the manager, plus network access to the cluster port.
Sources
Last reviewed: 18 October 2026.
