CVE-2026-67307 in Wazuh
Summary
by MITRE • 08/01/2026
Wazuh 5.0.0-beta1 (fixed in 5.0.0-beta3) does not validate or override the cluster_name and cluster_node fields in inventory-sync Start FlatBuffer messages, while validating only the agentid against the authenticated agent identity. This allows a low-privileged enrolled agent to spoof cluster attribution in indexed inventory and vulnerability documents by forging wazuh.cluster.name values and influencing the document _id prefix, potentially tampering with inventory records or, in shared-indexer multi-cluster deployments, poisoning another cluster's records when numeric agent IDs collide.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/01/2026
The vulnerability exists within Wazuh 5.0.0-beta1's cluster synchronization mechanism, specifically in how it processes inventory-sync Start FlatBuffer messages. This flaw represents a critical authorization bypass that undermines the integrity of cluster-based data management systems. The system fails to properly validate or override cluster_name and cluster_node fields while maintaining strict validation only for agentid against authenticated identity, creating a significant security gap in multi-cluster deployments.
The technical implementation of this vulnerability stems from insufficient input validation within the FlatBuffer message processing pipeline. When an enrolled agent sends inventory-sync messages, the system accepts forged cluster.name values without proper verification, allowing malicious actors to manipulate the document _id prefix through crafted wazuh.cluster.name fields. This design flaw creates a pathway for unauthorized data modification that operates at the core of Wazuh's distributed architecture.
The operational impact of this vulnerability extends beyond simple data corruption into potential system compromise and information integrity violations. In shared-indexer multi-cluster deployments, the vulnerability enables cluster poisoning attacks where one cluster's data can be overwritten or corrupted by another cluster's records. The collision risk becomes particularly dangerous when numeric agent IDs are reused across clusters, as it allows attackers to directly influence which documents get indexed and how they are structured within the Elasticsearch database.
This vulnerability aligns with CWE-284 Access Control Bypass and maps to ATT&CK technique T1566 Credential Stuffing and T1070 Indicator Removal on Host. The flaw demonstrates a classic privilege escalation vector where low-privileged agents can manipulate cluster metadata, potentially affecting system-wide inventory management and vulnerability assessment accuracy. Organizations relying on multi-cluster Wazuh deployments face increased risk of data integrity compromise and potential denial of service through systematic data corruption.
The recommended mitigation involves upgrading to Wazuh 5.0.0-beta3 or later versions where proper validation and override mechanisms have been implemented for cluster_name and cluster_node fields. Additionally, organizations should implement network segmentation between clusters, enforce stricter monitoring of inventory-sync message patterns, and consider implementing additional validation layers at the indexer level to detect anomalous cluster attribution patterns. Security teams must also review existing cluster configurations to ensure that agent ID collision scenarios are properly mitigated through administrative controls.