A maximum-severity vulnerability discovered in Wazuh Manager 5.0.0-beta1 allows any enrolled agent, including anonymously enrolled ones, to smuggle arbitrary OpenSearch _bulk API operations through a dangerously unescaped flatbuffer field, granting attackers full cluster-admin control over the backend indexer.
Tracked under GitHub Security Advisory GHSA-ff9g-85jq-r3g3 and published by researcher TarPeg007, the flaw carries a CVSS 3.1 score of 10.0 (Critical) and has no CVE assigned yet.
The vulnerability was patched in wazuh-manager 5.0.0-beta3. All 5.0 beta deployments still running beta1 or beta2 are exposed. Wazuh 4.x is not affected, as the vulnerable inventory_sync subsystem does not exist in that branch.
What Is the Vulnerability?
The flaw lives inside Wazuh’s new inventory pipeline, introduced in version 5.0. When an agent synchronizes inventory data, it sends a flatbuffer message containing a DataValue One field in that struct DataValue.index specifies the target OpenSearch index for the document being written.
The critical mistake: the inventory_sync module passes this agent-controlled string directly into an NDJSON _bulk request body without any sanitization, escaping, or validation.
Because OpenSearch’s _bulk API uses newline-delimited JSON, an attacker can embed literal newline characters (\n) and closing braces (}}) into the index field to break out of the intended JSON object and inject entirely new bulk operations.
Security researcher TarPeg007 identified that while the adjacent _id field is correctly sanitized via an appendEscapedId() function, the _index field receives no equivalent treatment, a plainly asymmetric and exploitable omission in indexerConnectorSyncImpl.hpp.
The attack is deceptively straightforward to execute. Wazuh’s default wazuh-authd configuration ships with use_password=no and ssl_verify_host=no, meaning any attacker can enroll a rogue agent anonymously over TCP port 1515 without credentials.
Once enrolled, the attack proceeds entirely over the standard remoted AES protocol on TCP port 1514, with no local access required and no configuration changes.
An attacker crafts a DataValue message where the index field contains a payload like:
wazuh-states-inventory-packages-default"}}
{}
{"delete":{"_index":"<TARGET_INDEX>","_id":"<TARGET_ID>"}}
{"index":{"_index":"xWhen the Wazuh Manager assembles the _bulk POST body and sends it to the Wazuh-indexer, OpenSearch parses what was intended as one bulk action as three separate operations, including the attacker’s injected delete command.
The entire request executes under the manager’s stored keystore credentials, which, in every shipped install template and the published wazuh-docker single-node compose, defaults to admin with the all_access role.
TarPeg007 verified this end-to-end using a custom Python agent emulator that implements the full enrollment, AES-256-CBC key derivation, and remoted framing protocol.
The proof-of-concept confirmed document deletion within 9 seconds of sending the poisoned DataValue message, with the manager’s own debug log confirming "result":"deleted","status":200 for the smuggling operation.
Scope of Impact
The consequences of successful exploitation are severe across several dimensions:
- Alert tampering and evidence destruction — Attackers can delete documents from
wazuh-alerts-*indices, erasing forensic evidence of an ongoing compromise. - Cross-agent SIEM manipulation — Inventory and vulnerability state can be overwritten for other agents, poisoning the SIEM’s view of the entire fleet.
- Persistent dashboard payloads — Writes to the
.kibana_1saved objects index can plant server-rendered payloads targeting security analysts reviewing dashboards. - Cross-tenant data access — In multi-tenant deployments where index naming is the only isolation boundary, attackers can read or modify data belonging to other tenants.
The vulnerability is classified under CWE-74 (Injection), CWE-93 (CRLF Injection), and CWE-863 (Incorrect Authorization), reflecting both the technical root cause and the authorization failure that amplifies its impact.
The source code tells a clear story. In inventorySyncFacade.hpp, the raw agent-supplied string is extracted and passed without modification to bulkIndex() and bulkDelete().
A grep across both inventory_sync and indexer_connector source directories returns zero hits for any index name validation function. No charset check, no length cap, and no call to any OpenSearch index-name validator exists between the flatbuffer field and the HTTP sink.
At the sink in indexerConnectorSyncImpl.hpp, the _index value is appended with a simple m_bulkData.append(index) on line 1183, while the _id field on the very next line goes through appendEscapedId(). The asymmetry makes the bug unmistakable.
The maintainer’s advisory outlines a three-layer remediation strategy. The minimum fix mirrors the existing appendEscapedId() logic for the _index field, adding an appendEscapedIndex() function that rejects newlines, carriage returns, double quotes, and control bytes.
The recommended fix validates index names at the boundary in inventorySyncFacade.hpp Before they ever reach the connector layer, enforcing OpenSearch’s own index-naming rules, including the 255-byte limit and banned characters.
As a defense-in-depth measure, the shipped installer templates and Docker Compose files should replace the admin/all_access keystore default with the narrower wazuh-server role, which ships with the OpenSearch security plugin and limits the blast radius of any future connector-layer bugs.
Organizations running Wazuh Manager 5.0.0-beta1 or beta2 should upgrade to 5.0.0-beta3 immediately. Given that beta deployments are sometimes deployed in lab or staging environments with relaxed network controls, defenders should also audit their Wazuh-authd configuration for anonymous enrollment and restrict access on TCP/1514 and TCP/1515 to known agent IP ranges as a compensating control while patching.
Frequently Asked Questions
Q1: Does this vulnerability affect Wazuh 4.x installations?
No, the inventory_sync subsystem that contains the vulnerable code was introduced in Wazuh 5.0 and does not exist in any 4.x branch.
Q2: Can an attacker exploit this without prior authentication or credentials?
Yes, Wazuh’s default wazuh-authd configuration allows anonymous agent enrollment with no password and no SSL host verification, making the precondition trivially met over a network.
Q3: What is the patched version and where can administrators download it?
The vulnerability is patched in Wazuh-manager 5.0.0-beta3, available through the official Wazuh GitHub repository and package repositories.
Q4: Is there a CVE assigned to this vulnerability?
No CVE identifier has been assigned yet at the time of publication; it is tracked under GitHub Security Advisory GHSA-ff9g-85jq-r3g3.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.
About the Author
