Description

Wazuh from 3.9.0 before 4.14.9 contains a missing TLS hostname verification vulnerability in the fluent-forward module's wm_fluent_ssl_ctx() that allows network attackers to impersonate the Fluentd collector by presenting any certificate chaining to the configured ca_file. Attackers who redirect the connection via DNS, ARP, or on-path positions can receive forwarded security telemetry and the shared_key_hexdigest for offline cracking.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-11-06T15:17:08.377Z",
  "pubdate": "2026-11-06T15:17:08.377Z",
  "executiveSummary": "Wazuh versions 3.9.0 through 4.14.8 are affected by a critical vulnerability involving missing TLS hostname verification within the fluent-forward module.\nThe vulnerability resides in the wm_fluent_ssl_ctx() function, which fails to validate the hostname against the presented certificate during the TLS handshake process.\nThis flaw enables network-based attackers capable of intercepting traffic to conduct man-in-the-middle (MitM) attacks by presenting any certificate signed by the trusted CA defined in ca_file.\nSuccessful exploitation allows an adversary to impersonate a legitimate Fluentd collector, facilitating the unauthorized interception of sensitive security telemetry and the exfiltration of the shared_key_hexdigest.\nThe leaked shared_key_hexdigest significantly lowers the barrier for subsequent offline brute-force or dictionary attacks, potentially compromising the integrity of the logging pipeline.\nThis vulnerability is particularly dangerous in environments where network traffic can be redirected through DNS spoofing, ARP poisoning, or on-path positioning, allowing attackers to position themselves transparently between the Wazuh agent and the destination collector.",
  "technicalDetails": "The root cause of this vulnerability is an improper implementation of TLS validation within the wm_fluent_ssl_ctx() function of the Wazuh fluent-forward module. While the module enforces the usage of a trusted CA via the ca_file configuration, it fails to perform mandatory hostname verification (Subject Alternative Name (SAN) or Common Name (CN) checking).\nUnder normal circumstances, a TLS client must verify that the identity presented by the server matches the hostname of the server it intends to connect to. In this vulnerable implementation, the client verifies only the chain of trust against the configured CA. Consequently, if an attacker provides a certificate that is cryptographically signed by the same trusted root CA, the client will erroneously accept the connection regardless of the identity associated with that certificate.\nThe attack flow begins with the attacker positioning themselves as a man-in-the-middle, typically via techniques such as ARP cache poisoning, DNS hijacking, or by operating on a compromised gateway. Once traffic is redirected, the attacker initiates a TLS connection to the Wazuh agent, presenting a spoofed certificate signed by the target environment's trusted CA.\nBecause the wm_fluent_ssl_ctx() function omits hostname validation, the agent completes the TLS handshake successfully, effectively trusting the attacker as the legitimate Fluentd collector. The agent then proceeds to transmit sensitive security telemetry data, including system logs, process execution data, and, critically, the shared_key_hexdigest used for authentication and data integrity.\nPost-exploitation, the attacker gains full visibility into the agent's telemetry stream, allowing for the exfiltration of sensitive infrastructure data. Furthermore, by capturing the shared_key_hexdigest, the attacker can perform offline cracking to derive the cleartext shared key. This key can then be used to inject malicious log events into the Wazuh manager, effectively poisoning the security intelligence pipeline, bypassing detection mechanisms, or facilitating further lateral movement within the network.\nThis vulnerability is present in Wazuh versions 3.9.0 up to 4.14.8 and requires no specific authentication or elevated privileges beyond the ability to influence network routing and the possession of a certificate signed by the configured CA."
}