Skip to content
Fencer Intel
low 2.2

GHSA-x5hg-x4gv-j98m json

OpenSearch has ineffective TLS certificate hostname verification

published 6mo ago modified 6mo ago

cvss
2.2
version 3.1, GitHub
cisa kev
Not listed
not in CISA's catalog
epss
—
no score, EPSS covers CVEs only
public exploits
0
none known

Summary

### Description

A regression was introduced in OpenSearch 2.18.0 that caused the `plugins.security.ssl.transport.enforce_hostname_verification` setting to be ineffective. When this setting was enabled, OpenSearch did not verify that the hostname in a connecting node's TLS certificate matched the hostname of the connection. This could allow a node with a valid certificate (signed by the cluster's trusted CA) but an incorrect hostname SAN to join the cluster.

### Impact

Clusters running affected versions with hostname verification enabled did not receive the expected protection from this setting. A node presenting a certificate signed by the cluster's trusted CA could join the cluster regardless of whether its hostname SAN matched. This regression does not affect certificate validation itself — only the additional hostname verification check.

### Patches

This issue is fixed in OpenSearch 2.19.4 and 3.3.0.

### Workarounds

Use more restrictive values for `plugins.security.nodes_dn` to limit which certificates are accepted for node-to-node communication.

Patch / fix

  • maven org.opensearch.plugin:opensearch-security 2.19.4.0, 3.3.0.0

Is GHSA-x5hg-x4gv-j98m in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

CVSS scores

assigned by version score vector
GitHub 3.1 2.2 CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N

Affected packages

ecosystem package affected fixed in
maven org.opensearch.plugin:opensearch-security
>=2.18.0, <2.19.4.0
>=3.0.0, <3.3.0.0
2.19.4.0
3.3.0.0

Classification

Weakness
  • CWE-295 Improper Certificate Validation

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.