Critical Wazuh Vulnerability Lets Attackers Delete Alerts and Tamper With SIEM Evidence

A critical Wazuh Manager vulnerability can let attackers tamper with alerts, delete forensic records, and manipulate security data stored in the platform’s indexer. The flaw affects Wazuh Manager 5.0.0-beta1 and is fixed in 5.0.0-beta3.

The issue is tracked as GHSA-ff9g-85jq-r3g3 and carries a CVSS 3.1 score of 10.0. GitHub’s advisory lists it as a critical NDJSON injection flaw in the new inventory_sync subsystem, specifically through the agent-controlled DataValue.index field.

The risk is serious because Wazuh often acts as a central security monitoring platform. According to the official Wazuh components documentation, the Wazuh indexer stores alerts generated by the Wazuh server, while the dashboard gives analysts access to threat hunting, compliance, vulnerability, and file integrity data.

Wazuh 5.0 Beta Flaw Targets the Inventory Sync Pipeline

The vulnerability sits in the Wazuh Manager inventory synchronization pipeline. In the affected code path, Wazuh forwards an agent-supplied index name into an OpenSearch bulk request without properly escaping or validating it.

That creates an NDJSON injection issue. A malicious or compromised enrolled agent can place newline characters and JSON fragments into the index field, causing the Wazuh Manager to send extra bulk actions to the indexer.

The advisory says the attacker can smuggle actions such as delete, index, or update into a request where Wazuh intended to perform only one operation. Those injected operations then run under the indexer credentials stored by the manager.

Detail	Status
Advisory ID	GHSA-ff9g-85jq-r3g3
Severity	Critical
CVSS score	10.0
Affected package	wazuh-manager
Affected version	5.0.0-beta1 and later 5.x builds with the same vulnerable code path
Patched version	5.0.0-beta3
CVE status	No known CVE listed
Unaffected branch	Wazuh 4.x

Why the Wazuh Vulnerability Is Dangerous

The flaw matters because it can affect the integrity of the security system itself. Instead of merely hiding on one endpoint, an attacker with access to an enrolled agent may be able to modify the central evidence store that analysts rely on during investigations.

The official GitHub security advisory says smuggled operations can delete documents in wazuh-* indices, overwrite inventory and vulnerability state for other agents, write to dashboard saved objects, and affect cross-tenant deployments where index separation is used as a boundary.

This can support post-compromise cleanup. An attacker could try to remove alerts, alter vulnerability data, or change records that would otherwise help investigators reconstruct an incident.

How an Attack Could Work

The exploit path depends on agent enrollment. If an attacker controls a Wazuh agent, or can enroll a rogue one, that agent can send a crafted inventory sync message to the manager.

The vulnerable manager then builds an OpenSearch bulk request using the untrusted index value. Because the index value is not safely neutralized, OpenSearch may parse the attacker’s added lines as separate bulk operations.

Wazuh agent enrollment deserves special attention here. The official password authentication guide says Wazuh can require a password during enrollment to ensure that agents enrolled in the manager are authenticated.

• A malicious agent enrolls or a legitimate agent is compromised.
• The agent sends a crafted DataValue.index value through the inventory sync flow.
• The manager inserts that value into an OpenSearch bulk request.
• OpenSearch treats the injected content as additional operations.
• The attacker can delete, overwrite, or add documents depending on indexer permissions.

Default or Weak Enrollment Settings Increase the Risk

The advisory highlights anonymous SSL enrollment over TCP port 1515 as a key precondition in default-style setups. In that situation, the bug can become easier to reach because the attacker may not need an already trusted endpoint.

Wazuh administrators should review enrollment hardening immediately. The Wazuh password authentication documentation explains how to enable use_password in the manager configuration and create an authd.pass file for agent enrollment.

Admins should also consider certificate-based verification. The manager identity verification documentation explains how Wazuh agents can verify the Wazuh Manager certificate before sending enrollment requests.

What Attackers Can Do After Exploitation

The most damaging outcome is silent evidence manipulation. Since the injected operations can run with the manager’s indexer role, the attacker may gain far more influence over stored SIEM data than a normal endpoint should have.

In a real incident, this can weaken incident response. If alerts or vulnerability records disappear, security teams may miss the original intrusion path, underestimate the scope of compromise, or lose evidence needed for compliance reporting.

The risk also extends to dashboards. The advisory says writes to saved dashboard objects may allow persistent content to reach analysts through the security interface, which creates another path for deception or follow-on targeting.

Possible attacker action	Security impact
Delete alert documents	Removes evidence of suspicious behavior
Overwrite inventory data	Changes endpoint state and asset records
Modify vulnerability state	Hides or changes exposure data for other agents
Write to dashboard objects	Can persist misleading or malicious dashboard content
Operate across indices	Creates cross-tenant risk in shared deployments

Who Needs to Patch

Organizations testing Wazuh 5.0.0-beta1 should upgrade to Wazuh Manager 5.0.0-beta3. Any later 5.x build that still contains the same vulnerable inventory_sync and indexer connector behavior should also be treated as exposed.

Wazuh 4.x users have a different risk profile. The advisory says Wazuh 4.x is not affected because the inventory_sync code path does not exist in that branch.

Even so, this vulnerability is a good reason to review the overall security model. The Wazuh platform architecture depends on agents, the server, the indexer, and the dashboard working together. If attackers can influence the data pipeline, they can undermine the trust analysts place in the platform.

Recommended Mitigations for Wazuh Admins

The first mitigation is to upgrade to the patched version. Since the flaw affects the security data pipeline, delaying the fix can leave organizations exposed to alert deletion and SIEM tampering.

Admins should also reduce the blast radius of any similar flaw by limiting indexer privileges. Avoid using broad admin or all-access roles for routine manager-to-indexer operations when a narrower service role can do the job.

Agent enrollment hardening should happen at the same time. Use password authentication, restrict who can enroll agents, and verify manager identity with certificates where possible. The official Wazuh certificate guidance describes how agents can validate the manager before enrollment.

• Upgrade Wazuh Manager to 5.0.0-beta3 or later fixed builds.
• Disable anonymous agent enrollment where possible.
• Enable password authentication for agent enrollment.
• Use certificate-based manager identity verification.
• Reduce indexer permissions used by the manager.
• Review logs for unexpected bulk delete, index, or update operations.
• Check dashboard saved objects for suspicious changes.
• Audit inventory and vulnerability state changes for cross-agent tampering.

Security teams should treat this as more than a normal patching task. The vulnerability affects the credibility of stored detection data, so incident responders should review recent indexer operations if they tested or deployed affected Wazuh 5.0 beta builds.

FAQ