CVE-2026-67307: 
Wazuh Server vulnerability analysis and mitigation

CVE-2026-67307 is a cluster attribution spoofing vulnerability in Wazuh affecting versions 5.0.0-beta1 through 5.0.0-beta2, fixed in 5.0.0-beta3. The flaw allows a low-privileged enrolled agent to forge cluster_name and cluster_node fields in inventory-sync Start FlatBuffer messages, enabling tampering with indexed inventory and vulnerability documents. It was published on August 1, 2026, with a CVSS v3.1 base score of 6.3 (Medium) and a CVSS v4.0 base score of 7.0 (High) (GitHub Advisory, Wazuh Advisory).

The root cause is CWE-345 (Insufficient Verification of Data Authenticity) and CWE-639 (Authorization Bypass Through User-Controlled Key). The Wazuh manager validates the agentid field in inventory-sync Start FlatBuffer messages against the authenticated agent identity, but does not validate or override the cluster_name and cluster_node fields supplied by the agent. In src/wazuh_modules/inventory_sync/src/agentSession.hpp, the agent-controlled values are copied directly into the session context, and in src/wazuh_modules/inventory_sync/src/inventorySyncFacade.hpp, the session context is used to generate the inventory document _id prefix and the wazuh.cluster.name indexed field — with the manager's authoritative cluster name used only as a fallback when the agent-supplied field is empty. An attacker with only a valid enrolled agent credential can exploit this over the network by sending a crafted FlatBuffer Start message with a forged cluster_name value (Wazuh Advisory).

A malicious enrolled agent can forge wazuh.cluster.name in inventory and vulnerability documents, influence the document _id prefix, and potentially orphan or hide inventory records from cluster-scoped dashboards or queries. In shared-indexer multi-cluster deployments, the attacker can overwrite or poison another cluster's inventory records when numeric agent IDs collide across clusters. There is no confidentiality or availability impact; the impact is entirely on data integrity and attribution accuracy within the Wazuh indexer (Wazuh Advisory, GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the publication date (GitHub Advisory). The NVD SSVC assessment classifies exploitation as "none" and the attack as non-automatable. The EPSS score is approximately 0.169% (7th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires a valid enrolled agent credential and specific deployment conditions (shared-indexer multi-cluster environment with colliding agent IDs for cross-cluster impact), raising the practical bar for abuse.

1. Obtain enrolled agent credentials: Register or compromise a Wazuh agent to obtain a valid agent enrollment credential for the target Wazuh 5.0.0-beta1 or beta2 manager.
2. Craft a malicious FlatBuffer Start message: Construct an inventory-sync Start FlatBuffer message containing the legitimate agentid (to pass authentication) but with attacker-controlled values for cluster_name (e.g., ATTACKER-CLUSTER) and cluster_node.
3. Send the forged message: Transmit the crafted FlatBuffer message to the Wazuh manager's inventory-sync endpoint over the network. The manager validates only the agentid and accepts the forged cluster attribution fields.
4. Submit synthetic inventory items: Send benign or crafted inventory items through the established session. The manager uses the attacker-supplied cluster_name to generate the document _id prefix and populate wazuh.cluster.name in indexed documents.
5. Achieve cross-cluster poisoning (multi-cluster scenario): In shared-indexer deployments, if the attacker's agent ID numerically collides with an agent ID in a target cluster, the forged documents will be indexed under the target cluster's namespace, overwriting or poisoning that cluster's inventory records (Wazuh Advisory).

• Indexer Documents: Inventory or vulnerability documents in the Wazuh indexer where wazuh.cluster.name does not match the manager's configured cluster name; document _id prefixes containing unexpected or unknown cluster name strings.
• Logs: Inventory-sync session logs showing cluster_name values that differ from the manager's authoritative configuration; repeated inventory-sync Start messages from a single agent with varying cluster_name values.
• Behavioral: Inventory records appearing under unexpected cluster namespaces in dashboards; orphaned or duplicate inventory records for the same agent ID attributed to different clusters in a shared-indexer environment (Wazuh Advisory).

Upgrade Wazuh to version 5.0.0-beta3 or later, which fixes the issue by ignoring agent-supplied cluster_name and cluster_node fields and always deriving cluster attribution from the manager's authoritative configuration (commit b3dae02ec9ddcfd449cb61b4c76d180e3e43f79a). No configuration-based workaround is available for the unpatched versions. Operators running shared-indexer multi-cluster deployments should prioritize patching to prevent cross-cluster record poisoning (Wazuh Advisory, Patch Commit).

The vulnerability was reported by security researcher nasaa0x and published by Wazuh maintainer vikman90 via a GitHub Security Advisory on July 16, 2026, with the CVE assigned and published on August 1, 2026. VulnCheck also published an advisory covering the issue. No significant broader media coverage or notable community discussion has been observed beyond the official advisory channels (Wazuh Advisory, GitHub Advisory).