CVE-2026-67307 is a medium severity (CVSS 6.3) flaw in Wazuh 5.0.0-beta1. An enrolled agent can spoof cluster attribution in indexed inventory and vulnerability documents. The fix is in 5.0.0-beta3. Production deployments on stable 4.x releases are not described by this advisory.
What's affected
The record and the Wazuh advisory list Wazuh manager 5.0.0-beta1 as affected and 5.0.0-beta3 as the patched version. The record's description says the flaw is fixed in 5.0.0-beta3.
The advisory text also says "Wazuh main / 5.0.0-beta3 at" a specific commit under affected version, which seems to conflict with beta3 being the fix. The patched version field and the record agree on beta3, so I take that as the fix, and I suggest you confirm the beta tag you run against the project's release notes.
Severity matches across sources. The record gives 6.3 and the Wazuh advisory says Moderate, 6.3. The weakness is CWE-345, insufficient verification of data authenticity.
According to the advisory, the manager validates the agent ID in the inventory-sync start message against the authenticated agent identity, but it trusts the cluster name and cluster node fields in the same message. Those values then appear in indexed inventory and vulnerability documents.
How to check if you're exposed
Find out whether you run a Wazuh 5.0 beta at all. On the manager:
/var/ossec/bin/wazuh-control info
The output shows the version. If it says 5.0.0-beta1, you are on the affected release. If you run a stable release, this advisory does not describe your version.
Then look at your design. The risk is highest in shared indexer, multi-cluster deployments where numeric agent IDs can collide across clusters. In a single cluster with a trusted set of agents, the impact is mostly confusing attribution.
What to do now
- Confirm the Wazuh version on every manager.
- Move beta testers to 5.0.0-beta3 or later.
- Do not run pre-release builds on production data.
- If you share an indexer between clusters, review inventory documents for cluster names that do not match their agents.
- Treat enrolled agent credentials as sensitive, since the attack needs only a valid one.
Why it matters
This is a data integrity issue, not a code execution issue. The advisory says the attacker does not need API administrator rights, cluster keys or local access to the manager. They need only a valid enrolled agent credential.
The effect is that inventory data, which defenders rely on to answer what is installed where, can be tagged with the wrong cluster. It may hide a record from a cluster scoped dashboard, or in the worst case overwrite another cluster's records when IDs collide. Trust in monitoring data is the asset at stake.
No source I reviewed says this CVE is exploited in the wild, and the record's KEV flag is false.
Quick check
Does this affect Wazuh 4.x?
The advisory lists only 5.0.0-beta1 as affected.
Can the agent impersonate another agent?
No. The advisory says the agent ID check works. Only the cluster fields are trusted.
Sources
Last reviewed: 18 October 2026.
