# Elasticsearch 8.19.24, 9.4.9, 9.5.6 Security Update (ESA-2026-227)

**URL:** <https://discuss.elastic.co/t/elasticsearch-8-19-24-9-4-9-9-5-6-security-update-esa-2026-227/391364>\
**Category:** Security Announcements\
**Tags:** docker\
**Created:** [November 3, 2026, 4:30pm UTC](https://discuss.elastic.co/t/elasticsearch-8-19-24-9-4-9-9-5-6-security-update-esa-2026-227/391364 "2026-11-03T16:30:02Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bryan\_Garcia](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bryan_garcia/32/148179_2.png) [@Bryan\_Garcia](https://discuss.elastic.co/u/Bryan_Garcia)\
**Post date:** [November 3, 2026, 4:30pm UTC](https://discuss.elastic.co/t/elasticsearch-8-19-24-9-4-9-9-5-6-security-update-esa-2026-227/391364/1 "2026-11-03T16:30:02Z")

</div>

**Improper Certificate Validation in Elasticsearch Leading to Interception of TLS Connections**

Improper Certificate Validation (CWE-295) in the Java runtime bundled with Elasticsearch, a dependency of Elasticsearch (Dependency on Vulnerable Third-Party Component, CWE-1395), could allow an attacker to intercept or modify TLS-protected traffic via Signature Spoofing by Key Theft (CAPEC-474). The trust store of the bundled Java runtime includes root certificate authorities that signed eight eMudhra intermediate certificate authorities whose private keys are compromised. Anyone with these keys can issue a certificate for any host name that Elasticsearch accepts as trusted. Exploitation requires an attacker in a network position between Elasticsearch and the remote party, who presents a certificate issued with one of the compromised keys that triggers CVE-2026-91403 and CVE-2026-114820.

**Affected Versions:**

> - 8.x: All versions from 8.12.1 up to and including 8.19.23
> - 9.x:

- All versions from 9.0.0 up to and including 9.4.8
- All versions from 9.5.0 up to and including 9.5.5

**Affected Configurations:**

> - Elasticsearch deployments that run on the bundled Java runtime, including the Elasticsearch Docker images.
> - The issue affects TLS connections for which Elasticsearch uses the default trust store of the Java runtime to verify certificates. This is the case when no specific certificate authorities or trust store are configured for that connection. Examples include connections to snapshot repositories, reindex from a remote cluster, Watcher HTTP actions, and the retrieval of identity provider metadata or signing keys.

**Solutions and Mitigations:**

The issue is resolved in versions 8.19.24, 9.4.9, and 9.5.6. These versions update the bundled Java runtime to 27.0.1.0.3 and remove the affected eMudhra root certificate authorities from the trust store of the bundled Java runtime.

The versions above are the first releases verified to contain the fix. Elastic recommends upgrading to one of these fixed versions or a later release verified to contain the fix, and reviewing the [known issues](https://www.elastic.co/docs/release-notes) for your target version before upgrading.

**For Users that Cannot Upgrade:**

> - Self-hosted: Remove the affected root certificates from the trust store of the bundled Java runtime on each node, then restart the node. Use the keytool utility of the bundled Java runtime. The affected root certificates are emSign Root CA - G1, emSign Root CA - G2, emSign ECC Root CA - G3, and AAA Certificate Services, as listed in the [OpenJDK guidance on the compromised eMudhra certificates](https://openjdk.org/emudhra). Removing these roots causes TLS connections to fail for remote services whose certificates chain only to these roots.
> - Self-hosted: Alternatively, run Elasticsearch on an updated Java runtime from your Java vendor that removes the affected root certificate authorities.

> 

**Indicators of Compromise (IOC)**

No specific indicators of compromise have been identified for this vulnerability.

**Elastic Cloud Serverless**

Due to our continuous deployment and patching model, the vulnerability described in this security advisory was remediated in our Elastic Cloud Serverless offering before the public disclosure.

**Severity:** CVSSv3.1: High ( 7.4 ) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N  
**CVE ID:** CVE-2026-91403, CVE-2026-114820  
**Problem Type:** CWE-295 - Improper Certificate Validation  
**Impact:** CAPEC-474 - Signature Spoofing by Key Theft
