Listen to this Post
A regression introduced in OpenSearch 2.18.0 breaks the `plugins.security.ssl.transport.enforce_hostname_verification` setting. When this setting is enabled, OpenSearch fails to verify that the hostname in a connecting node’s TLS certificate matches the actual hostname. The issue arises from a logic flaw in the TLS hostname validation routine, which was inadvertently skipped during the 2.18.0 code merge. Consequently, a node with a valid certificate signed by the cluster’s trusted CA can join the cluster even if its certificate lacks the correct Subject Alternative Name (SAN) for the intended host. This weakness persists through OpenSearch versions 2.18.0 up to 2.19.3 (and 3.0.0 through 3.2.x). Standard certificate chain validation remains intact, but the extra hostname check – intended to prevent man‑in‑the‑middle attacks – is completely ignored. The regression does not affect earlier versions (2.17.x and below) or fixed versions 2.19.4 and 3.3.0. Administrators who rely on hostname verification for node‑to‑node security are unprotected until they upgrade or apply the `plugins.security.nodes_dn` workaround. The issue is tracked as low severity because it still requires a valid certificate signed by the cluster’s CA, but it significantly weakens transport‑layer security.
Platform: OpenSearch Security Plugin Version: 2.18.0‑2.19.3 & 3.0.0‑3.2.x Vulnerability : Hostname verification regression Severity: Low date: 2026‑04‑30 Prediction: Patches available 2.19.4/3.3.0
Analytics under What Undercode Say
Check current OpenSearch version curl -s -X GET "https://localhost:9200" -k Verify hostname verification setting in opensearch.yml grep -i "plugins.security.ssl.transport.enforce_hostname_verification" /etc/opensearch/opensearch.yml Enable hostname verification (if not already set) echo 'plugins.security.ssl.transport.enforce_hostname_verification: true' >> /etc/opensearch/opensearch.yml Restart OpenSearch for changes to take effect systemctl restart opensearch List cluster nodes and check for unexpected members curl -s -X GET "https://localhost:9200/_cat/nodes?v" -k Test TLS connection with a mismatched hostname (simulating attack) openssl s_client -connect malicious-node:9300 -servername fakehost
Exploit
An attacker who obtains a certificate signed by the cluster’s trusted CA can present that certificate during node‑to‑node handshake. Because OpenSearch does not enforce hostname verification, the attacker’s node is accepted into the cluster even if its certificate’s SAN does not match the expected hostname. The attacker can then query data, index documents, or escalate privileges depending on the node’s role.
Protection from this CVE
- Upgrade to OpenSearch 2.19.4 or 3.3.0 (or later).
- If an immediate upgrade is not possible, enforce stricter `plugins.security.nodes_dn` values to limit which certificates are trusted.
- Monitor cluster membership logs for unexpected node joins.
Impact
Clusters running affected versions lose the intended protection of hostname verification. An adversary with a valid but mis‑issued certificate can impersonate a legitimate node, leading to unauthorized data access, cluster destabilization, or privilege escalation. The vulnerability does not bypass certificate chain validation, but it removes a critical defence against certificate‑based impersonation attacks.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
