Critical Wazuh Flaw Enables Threat Actors to Alter Alerts and Remove Logs

A critical security flaw in Wazuh Manager could allow unauthenticated threat actors to tamper with alerts, delete forensic evidence, and execute arbitrary OpenSearch operations by exploiting an input validation weakness in the platform’s new inventory synchronization pipeline.

Tracked under GitHub advisory GHSA-ff9g-85jq-r3g3, the vulnerability affects Wazuh Manager version 5.0.0-beta1 and carries a maximum CVSS score of 10.0.

The issue stems from improper neutralization of agent-controlled input in the inventory_sync module, enabling a powerful NDJSON injection attack that compromises the integrity of security telemetry stored in Wazuh’s OpenSearch backend.

Critical Wazuh Flaw

The root cause lies in how Wazuh processes the DataValue.index field, which enrolled agents supply. This field is directly embedded into OpenSearch _bulk API requests without sanitization or validation.

Unlike other fields such as _id, which undergo escaping, the _index value is appended as raw input, creating an injection primitive that attackers can exploit to execute arbitrary bulk operations.

Because Wazuh’s default configuration permits anonymous agent enrollment (use_password=no) over TCP port 1515, an attacker can register a rogue agent without authentication.

Once enrolled, the attacker can craft a malicious DataValue.index payload containing newline characters and additional JSON actions, effectively smuggling unauthorized operations into the bulk request sent by the Wazuh Manager.

A simplified example of the vulnerable code path shows how unsanitized input is appended directly into the NDJSON payload:

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

By injecting payloads such as:

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

An attacker can force the Wazuh Manager to execute unintended operations under its own privileges. Since the manager authenticates to OpenSearch using credentials stored in its keystore, typically configured with admin and all_access roles in default deployments, the injected commands execute with full cluster-level permissions.

This enables several high-impact attack scenarios, including deleting alert logs (wazuh-alerts-*), manipulating vulnerability or inventory data across agents, and inserting persistent payloads into .kibana_1 dashboards viewed by analysts.

In multi-tenant environments, the flaw could also allow cross-tenant data tampering where index-level isolation is the only control boundary.

Notably, the vulnerability requires no user interaction. It can be executed remotely over the standard Wazuh remote protocol (TCP/1514), making it highly exploitable in real-world deployments.

Researchers demonstrated full end-to-end exploitation, including successful deletion of attacker-chosen documents, with OpenSearch returning “result”:”deleted” under legitimate manager credentials.

The issue is classified under multiple CWEs, including CWE-74 (injection), CWE-93 (CRLF injection), and CWE-863 (incorrect authorization), highlighting both input validation failures and broken trust boundaries between agents and the manager.

Wazuh has addressed the vulnerability in version 5.0.0-beta3 by introducing proper escaping of the _index field and recommending stricter validation at ingestion points. A secure implementation mirrors existing protections used for _id fields:

appendEscapedIndex(m_bulkData, index); // Sanitized input handling

Additionally, administrators are advised to enforce OpenSearch index-naming rules and avoid overly permissive roles, such as admin/all_access , for the manager’s keystore credentials. Transitioning to least-privileged roles, such as wazuh-server , significantly reduces the blast radius of potential exploitation.

Given the ease of exploitation and the critical impact on data integrity and availability, organizations using Wazuh 5.x beta releases should upgrade immediately and review index access controls, agent enrollment settings, and OpenSearch role configurations to mitigate risk.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.