Wazuh 4.14.7: a leaked cluster key can lead to root RCE

Wazuh 4.14.7 fixes a set of vulnerabilities best analysed as a chain rather than six isolated numbers. CVE-2026-61802 and CVE-2026-61783 disclose the shared cluster key to low-privilege accounts. CVE-2026-61800 lets a holder of that key write, overwrite or delete files under /var/ossec on workers, potentially reaching root code execution. CVE-2026-54083 and CVE-2026-54085 concern privileged Active Response scripts, while CVE-2026-54084 crashes an agent during enrolment through an unverified manager.

The records reached NVD on 28 August, while the project’s GitHub advisories were published on 18 August. Today’s date therefore marks broader catalogue visibility. Administrators should move to Wazuh 4.14.7 or a newer supported release and perform a controlled secret rotation after possible exposure of cluster.key.

This matters because Wazuh is a security platform with access to logs, agents and response actions on hosts. Compromise of its management plane can disable detection, alter evidence or turn a trusted defensive channel into a path across multiple systems.

CVE-2026-61802: an unmasked endpoint returns cluster.key

The Wazuh API has a mask_sensitive_config decorator that hides authd.pass and cluster.key from users lacking configuration-update permission. Most configuration-reading endpoints applied it. GET /cluster/local/config did not.

The endpoint required only cluster:read. Default readonly and cluster_readonly roles satisfy that condition although they intentionally cannot update configuration. The response contained the real key rather than a masked value. The advisory rates the disclosure CVSS 3.1 6.5 (Medium) and identifies versions 4.14.0–4.14.6; 4.14.7 is patched.

The cluster secret authenticates and encrypts master-to-worker traffic. Reading it does not execute code by itself. It does, however, supply the authentication prerequisite for known cluster-protocol attacks when the cluster port is reachable. This is a case where one CVE’s base score does not express the blast radius of a composable chain.

CVE-2026-61783: a deny rule paradoxically disables masking

The second disclosure has a different mechanism. A function deciding whether a user could update configuration treated the mere presence of manager:update_config or cluster:update_config as sufficient. It did not evaluate the rule effect. An explicit deny added to harden a read-only account was therefore interpreted as update permission.

Once the check considered the user capable of updating, the decorator stopped masking secrets. A raw-configuration request could return cluster.key in clear text. Versions 4.14.0–4.14.6 are affected, the score is CVSS 4.0 7.0 (High), and 4.14.7 fixes it.

This deserves a distinct regression test. A policy engine cannot answer only “does a matching entry exist?” It must evaluate action, resource, allow/deny effect, precedence and the final decision. A negative rule is a denial—not evidence of broader rights.

CVE-2026-61800: the cluster key opens worker file writes

Cluster file synchronisation used safe_join() to keep a destination under /var/ossec. That addressed .. traversal outside the base, but the non-merged file branch lacked a second check: whether the destination remained inside the directory declared by its cluster_item_key.

A malicious or compromised master—or a party with the cluster key and network access—could consequently place a file anywhere under /var/ossec, not only in the permitted synchronisation subtree. The deletion branch had the same gap. Because root processes execute some files in this tree, the advisory documents a path to root RCE on workers.

Versions 4.4.0–4.14.6 are affected, 4.14.7 contains the fix, and the score is CVSS 3.1 9.1 (Critical). This was an incomplete fix for CVE-2026-30893: the earlier control kept a path within /var/ossec but did not enforce the correct child directory.

Building the chain from readonly to root

In a realistic scenario, an API account with cluster:read obtains the key through CVE-2026-61802. If the attacker can reach the cluster port, the secret permits authentication as a peer. CVE-2026-61800 then redirects a synchronised file to a location executed with root privileges.

This is not one unauthenticated internet request that produces RCE. It requires a low-privilege account and reachability of the cluster service. Segmenting port 1516 and restricting roles reduces risk but does not replace either fix: a readonly account must not know the secret, and an authenticated peer must not choose arbitrary paths.

CVE-2026-61783 can supply the same key under a particular RBAC policy shape. Exposure analysis must therefore examine both endpoints and both role patterns, not only the default cluster_readonly role.

CVE-2026-54083: srcip becomes a root-owned path

The ip-customblock script built a file name by appending the alert’s srcip value to /ipblock/, but did not prove that the value was an IP address. Directory-changing sequences could move the operation outside its intended base. The block action created a file and the unblock action removed the selected path; Active Response runs with root privileges.

The issue carries CVSS 3.1 8.1 (High) and is fixed in 4.14.7. Reachability requires an attacker to place data into a log or alert that matches a rule invoking this exact script. Not every deployment uses ip-customblock, so an inventory of configured responses is more useful than merely finding the binary on disk.

CVE-2026-54085: alert data becomes command arguments

Five scripts processing srcip—including handlers for route, pf, npf, ipfw and Windows netsh—did not use the format validation present in sibling scripts. disable-account passed dstuser to account-management tools after blocking only the literal name root. Alert-derived data could therefore influence extra arguments to privileged commands.

Versions 4.2.0–4.14.6 are affected, the score is 7.1 (High) and 4.14.7 is fixed. A controlled syslog event is one possible source, but exploitation requires a matching rule and Active Response execution. That prerequisite does not justify trust in alert fields: a SIEM consumes hostile data and automation amplifies its effect.

CVE-2026-54084: enrolment without a CA can crash an agent

During enrolment, an agent split a key response into four fields. In affected releases, absent elements remained NULL, and a later validator called strlen() on them, terminating the process. A malicious manager or a man-in-the-middle could deterministically crash the agent.

Versions 4.0.0–4.14.6 are affected and the issue carries CVSS 3.1 5.3 (Medium). The practical condition is enrolment without correct CA verification of the manager. The update fixes the memory error, but TLS validation remains necessary so that agents do not trust arbitrary enrolment servers.

Remediation plan for SOC and platform teams

Upgrade managers and agents to 4.14.7 or a newer supported release in the order recommended by Wazuh. Preserve configuration, role mappings, node inventory, cluster state and custom Active Response scripts before changing. Afterwards, run cluster health checks and controlled negative tests against configuration endpoints.

If any low-privilege account could read cluster.key, treat the secret as potentially disclosed. Restrict the cluster port, remove unauthorised accounts, patch every node and then rotate the key through a planned procedure. Changing it on only part of the cluster breaks communication, so this is not an impulsive one-command response.

Identify Active Response scripts actually bound to rules. Until the update, disable scripts processing unvalidated fields or constrain their data sources and actions. After patching, test valid IPv4 and IPv6 values as well as rejected input; stricter validation should not silently break legitimate response automation.

Detection and evidence review

Review calls to /cluster/local/config and raw-configuration endpoints by readonly roles. A pre-fix read does not prove follow-on exploitation, but it identifies accounts for investigation. Correlate those calls with connections to the cluster port, master changes, unknown nodes and file synchronisation to unusual subdirectories.

On workers, compare files under /var/ossec with installed packages and the approved configuration repository. Focus on modification times for root-executed scripts, configuration and Active Response content. Do not immediately delete suspicious objects; collect metadata and an analysis copy first.

For CVE-2026-54083 and 54085, find alerts with unusual srcip or dstuser values followed by response execution. Examine actual command arguments, firewall changes, created files and account locks. For enrolment, look for agent crashes immediately after a manager response and installations without a configured CA.

Primary facts and Breachroad conclusions

Mechanisms, affected ranges, scores and the 4.14.7 fixes come from CNA records and official Wazuh repository advisories. The producer also documents CVE-2026-61802 plus CVE-2026-61800 as a reachable chain when the cluster port is accessible. Rotation order, telemetry priorities and test planning are Breachroad’s defensive conclusions. Public sources do not confirm exploitation at a named organisation.

Primary sources

• GHSA-chmg-89pf-2q82 — missing cluster.key masking
• GHSA-vjcq-cf36-f5gx — incorrect deny-effect handling
• GHSA-3jff-488g-335f — worker file write
• GHSA-m4mf-qmhf-8vj6 — ip-customblock path traversal
• GHSA-mvh4-g699-984j — Active Response argument injection
• GHSA-ppc7-hj9v-vx39 — agent enrolment crash

SIEM and XDR systems must treat their own inputs as adversarial. Our cybersecurity training for technical teams covers safe response automation, secret management and vulnerability chaining. Web, API and infrastructure penetration testing can validate RBAC, cluster segmentation and management-plane boundaries within an agreed scope.