CVSS 10.0 Critical Vulnerability in Wazuh Manager: NDJSON Injection Allows Full Cluster Compromise

A high-severity security flaw has been identified within the Wazuh Manager’s inventory synchronization pipeline, presenting a significant risk to the integrity of security telemetry. This vulnerability allows unauthenticated threat actors to manipulate alerts, purge forensic evidence, and execute arbitrary commands against the OpenSearch backend. By exploiting a failure in input validation, an attacker can effectively hijack the manager’s trusted connection to the data layer.

Tracked under GitHub Advisory GHSA-ff9g-85jq-r3g3, the vulnerability affects Wazuh Manager version 5.0.0-beta1 and has been assigned a maximum CVSS score of 10.0, reflecting its ease of exploitation and devastating potential impact.

Technical Analysis: The NDJSON Injection Primitive

The vulnerability resides within the inventory_sync module. The core issue is the improper neutralization of agent-controlled input during the construction of Newline Delimited JSON (NDJSON) payloads. Specifically, the manager fails to sanitize the DataValue.index field provided by enrolled agents.

When the Wazuh Manager prepares to synchronize inventory data, it aggregates information into a bulk request for the OpenSearch Bulk API. While the system correctly escapes certain metadata fields like _id, it treats the _index value as trusted raw input. This creates a classic injection primitive where an attacker can break out of the intended JSON structure.

In many default deployments, Wazuh is configured to allow anonymous agent enrollment (use_password=no) over TCP port 1515. This allows an adversary to register a rogue agent remotely. Once the rogue agent is “trusted” by the manager, it can transmit a specially crafted DataValue.index payload containing CRLF (Carriage Return Line Feed) characters to smuggle additional JSON commands into the bulk stream.

Consider this simplified view of the vulnerable logic path:

m_bulkData.append(R"({"index":{"_index":")");
m_bulkData.append(index); // <--- This is the unsanitized injection point
m_bulkData.append(R"("}})");
m_bulkData.append("\n");

By injecting a payload such as wazuh-states-inventory"}} \n {"delete":{"_index":"wazuh-alerts-*","_id":"target-doc"}} \n {"index":{"_index":"x, the attacker forces the manager to terminate the legitimate index command and start a new, unauthorized command—such as a mass deletion of security alerts.

Impact and Exploitation Scenarios

The danger of this flaw is amplified by the privilege model of the Wazuh Manager. Because the manager authenticates to OpenSearch using highly privileged credentials (often assigned the all_access role), any injected command is executed with full administrative authority over the entire OpenSearch cluster.

This leads to several critical attack vectors:

  • Forensic Erasure: Deleting wazuh-alerts-* indices to hide traces of a breach.
  • Data Corruption: Manipulating vulnerability assessments or agent inventory data to mislead security analysts.
  • Cross-Tenant Compromise: In multi-tenant environments relying on index-level isolation, an attacker could potentially breach the boundaries between different clients.
  • Dashboard Manipulation: Injecting malicious payloads into .kibana_1 indices to target analysts viewing dashboards.

Research has confirmed that this is a remote, zero-interaction exploit. It can be executed over the standard Wazuh remote protocol (TCP/1514), making it highly actionable for remote attackers.

Remediation and Best Practices

Wazuh has released a fix in version 5.0.0-beta3. The patch implements strict escaping for the _index field, ensuring that any injected newline characters or JSON delimiters are treated as literal strings rather than control characters. The corrected logic follows a pattern similar to existing protections:

appendEscapedIndex(m_bulkData, index); // Sanitized and safe

Defense-in-Depth Recommendations

Beyond immediate patching, security administrators should implement the following hardening measures:

  1. Enforce Least Privilege: Avoid using admin or all_access roles for the Wazuh Manager’s OpenSearch credentials. Transitioning to a custom role with restricted permissions (e.g., wazuh-server) limits the “blast radius” of an injection.
  2. Secure Agent Enrollment: Disable anonymous enrollment (set use_password=yes) to prevent unauthorized rogue agents from joining the cluster.
  3. Index Access Control: Implement strict OpenSearch index-level permissions to ensure that even a compromised service account cannot perform destructive operations across the entire cluster.

Immediate Action Required: Organizations running Wazuh 5.x beta releases should prioritize upgrading to version 5.0.0-beta3 or later immediately.

Related Articles

Back to top button