Critical Wazuh Flaw Lets Attackers Tamper Alerts &

A critical security flaw has been disclosed in Wazuh Manager, potentially allowing remote attackers to manipulate security alerts, delete forensic evidence, and tamper with SIEM data across environments.

The vulnerability carries a maximum CVSS score of 10.0, highlighting its severe impact and ease of exploitation.

The issue affects Wazuh Manager version 5.0.0-beta1 and stems from an NDJSON injection flaw in the newly introduced inventory_sync subsystem.

m_bulkData.append(R"({"index":{"_index":")");
m_bulkData.append(index); // Untrusted input
m_bulkData.append(R"("}})");
m_bulkData.append("n");

The vulnerability allows a malicious or compromised agent to inject arbitrary OpenSearch bulk operations by abusing the DataValue.index field, which is improperly handled without sanitization.

Wazuh Vulnerability

Wazuh Manager forwards agent-supplied data directly to the OpenSearch _bulk API. However, while fields such as _id are properly escaped, the _index field is appended without validation or filtering.

This inconsistency enables attackers to inject additional operations, such as delete, index, or update, into the request payload.

By injecting payloads such as:

wazuh-states-inventory"}}
{}
{"delete":{"_index":"wazuh-alerts-*","_id":"target-doc"}}
{"index":{"_index":"x

By embedding specially crafted newline characters and JSON fragments into the index field, an attacker can smuggle unauthorized bulk actions into the index.

These malicious operations are executed under the Wazuh indexer credentials, which, by default, often have admin privileges with full access.

The attack requires no authentication because of insecure default configurations in wazuh-authd that allow anonymous agent enrollment.

Once enrolled, an attacker can: Delete arbitrary documents from Wazuh indices, effectively erasing alerts and logs.

Modify vulnerability and inventory data for other agents. Inject malicious content into Kibana dashboards for persistence or analyst targeting. Perform cross-tenant data manipulation in shared environments.

Researchers demonstrated a full end-to-end exploit over standard Wazuh communication channels (TCP ports 1514 and 1515), confirming that injected delete operations successfully removed targeted records from the backend.

The vulnerability is primarily categorized under CWE-74 (Injection), along with CWE-93 (CRLF Injection) and CWE-863 (Incorrect Authorization).

The root cause lies in the lack of input validation and improper neutralization of special characters in the DataValue.index field.

Because the Wazuh Manager uses high-privileged OpenSearch credentials stored in its keystore, the flaw effectively grants attackers administrative control over the security data it indexes.

According to the GitHub advisory GHSA-ff9g-85jq-r3g3, the issue has been fixed in Wazuh version 5.0.0-beta3. Users are strongly advised to upgrade immediately.

Recommended Mitigations

Implement strict validation for index names based on OpenSearch rules. Escape all user-controlled input before constructing bulk requests.

Avoid using high-privilege roles, such as admin, for indexer operations. Disable anonymous agent enrollment and enforce secure authentication.

This vulnerability poses a significant risk to organizations relying on Wazuh for threat detection and response.

By enabling silent data tampering and evidence removal, attackers can evade detection and undermine trust in security monitoring systems.

Organizations using affected versions should treat this as a priority patching event and review logs for any signs of unauthorized index modifications.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.