CVE-2026-115714: Elastic Docker images: compromised eMudhra CAs enable TLS MITM

HIGH
Published November 3, 2026
CISO Take

Elastic's Docker images for APM Server, the Beats family, Elastic Agent, Fleet Server, Logstash, connectors, Universal Profiling and Maps Server ship an OS certificate bundle that trusts root CAs behind eight eMudhra intermediate CAs whose private keys are compromised. Anyone holding those keys can mint a certificate for any hostname that these products will accept as trusted. Exploitation needs a network position between the product and its remote peer, which is why the CVSS score is 7.4 (high) rather than critical. There is no EPSS score, no public exploit, no Nuclei template and no CISA KEV listing, so there is no sign of active exploitation yet. Telemetry and log pipelines often carry model-serving metrics, prompts in logs and credentials, and they sit next to AI/ML workloads, so the confidentiality and integrity risk is real. Upgrade to the fixed image versions in Elastic advisory ESA-2026-237 (8.19.24, 9.4.9 or 9.5.6 as listed there), rebuild and redeploy containers, and pin outbound TLS to specific CAs where you can.

Sources:NVDdiscuss.elastic.coATLAS

What is the risk?

High severity (CVSS 7.4) but constrained: the attacker must be on-path (AV:N/AC:H) and present a certificate signed with a compromised eMudhra intermediate key. No privileges or user interaction are needed. Impact is high for confidentiality and integrity and none for availability. Exposure is greatest where agents or connectors reach external endpoints across untrusted networks. No exploit code, KEV listing or EPSS data is available, so the likelihood of mass exploitation is currently low to moderate. This is a general platform trust-store issue and not specific to AI.

How does the attack unfold?

Obtain compromised CA key
The attacker acquires one of the eight compromised eMudhra intermediate CA private keys.
Network positioning
The attacker gets on-path between the Elastic container and its remote TLS peer.
Forge certificate and intercept
The attacker presents a certificate for the target hostname that the OS bundle trusts, and terminates TLS.
AML.T0010
Impact
The attacker reads or tampers with telemetry, credentials or connector data in transit.

How severe is it?

CVSS 3.1
7.4 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Advanced

What is the attack surface?

AVACPRUISCIA
AVNetwork
ACHigh
PRNone
UINone
SUnchanged
CHigh
IHigh
ANone

What should I do?

1 step
  1. 1) Upgrade to the patched Elastic Docker images named in ESA-2026-237 (the 8.19.24, 9.4.x and 9.5.x lines) and redeploy every container that uses them. 2) Rebuild any custom images derived from the affected base images so they pick up the updated CA bundle. 3) Where feasible, configure explicit CA pinning or a custom CA bundle for outbound TLS from Beats, Agent, Logstash and connectors, and remove the eMudhra roots if they are not needed. 4) Use private connectivity or mTLS for sensitive pipelines. 5) Detection: look for TLS sessions whose peer certificates chain to eMudhra intermediates, and for unexpected certificate issuers on known destinations. Monitor for new certificates issued for your domains using Certificate Transparency logs.

How is it classified?

Supply ChainData LeakageFrameworkAML.T0010

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
A.10.3-Suppliers
NIST AI RMF
GOVERN 6.1-Third-party risk policies and procedures
OWASP LLM Top 10
LLM03-Supply Chain

Frequently Asked Questions

What is CVE-2026-115714?

Elastic's Docker images for APM Server, the Beats family, Elastic Agent, Fleet Server, Logstash, connectors, Universal Profiling and Maps Server ship an OS certificate bundle that trusts root CAs behind eight eMudhra intermediate CAs whose private keys are compromised. Anyone holding those keys can mint a certificate for any hostname that these products will accept as trusted. Exploitation needs a network position between the product and its remote peer, which is why the CVSS score is 7.4 (high) rather than critical. There is no EPSS score, no public exploit, no Nuclei template and no CISA KEV listing, so there is no sign of active exploitation yet. Telemetry and log pipelines often carry model-serving metrics, prompts in logs and credentials, and they sit next to AI/ML workloads, so the confidentiality and integrity risk is real. Upgrade to the fixed image versions in Elastic advisory ESA-2026-237 (8.19.24, 9.4.9 or 9.5.6 as listed there), rebuild and redeploy containers, and pin outbound TLS to specific CAs where you can.

Is CVE-2026-115714 actively exploited?

No confirmed active exploitation of CVE-2026-115714 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-115714?

1) Upgrade to the patched Elastic Docker images named in ESA-2026-237 (the 8.19.24, 9.4.x and 9.5.x lines) and redeploy every container that uses them. 2) Rebuild any custom images derived from the affected base images so they pick up the updated CA bundle. 3) Where feasible, configure explicit CA pinning or a custom CA bundle for outbound TLS from Beats, Agent, Logstash and connectors, and remove the eMudhra roots if they are not needed. 4) Use private connectivity or mTLS for sensitive pipelines. 5) Detection: look for TLS sessions whose peer certificates chain to eMudhra intermediates, and for unexpected certificate issuers on known destinations. Monitor for new certificates issued for your domains using Certificate Transparency logs.

What systems are affected by CVE-2026-115714?

This vulnerability affects the following AI/ML architecture patterns: Observability and telemetry pipelines, Log ingestion (Logstash, Beats, Elastic Agent), Containerized ML infrastructure, Data connectors feeding RAG indexes.

What is the CVSS score for CVE-2026-115714?

CVE-2026-115714 has a CVSS v3.1 base score of 7.4 (HIGH).

What is the AI security impact?

Affected AI Architectures

Observability and telemetry pipelinesLog ingestion (Logstash, Beats, Elastic Agent)Containerized ML infrastructureData connectors feeding RAG indexes

MITRE ATLAS Techniques

AML.T0010AI Supply Chain Compromise

Compliance Controls Affected

ISO 42001: A.10.3
NIST AI RMF: GOVERN 6.1
OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

Improper Certificate Validation (CWE-295) in the operating system certificate bundle shipped in the Docker images of APM Server; Auditbeat, Filebeat, Heartbeat, Metricbeat and Packetbeat; Elastic Agent, including Fleet Server and Cloudbeat; Logstash, for TLS connections that use the operating system certificate bundle; Elastic connectors; Universal Profiling (host agent, collector and symbolizer); and Elastic Maps Server. This certificate bundle, a dependency of these products (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 certificate bundle 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 these products accept as trusted. Exploitation requires an attacker in a network position between the product and the remote party, who presents a certificate issued with one of the compromised keys.

Exploitation Scenario

An attacker positions themselves on the network path between an Elastic Agent or Logstash container and a remote endpoint, for example through a compromised router, rogue Wi-Fi or DNS/BGP manipulation. Using one of the leaked eMudhra intermediate CA private keys, they issue a certificate for the target hostname. The container trusts it because the root is in its OS bundle, so TLS is established with the attacker. The attacker then reads or modifies the telemetry, credentials or connector data in transit, including logs from an ML inference platform.

Weaknesses (CWE)

CWE-295 — Improper Certificate Validation: The product does not validate, or incorrectly validates, a certificate.

  • [Architecture and Design, Implementation] Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
  • [Implementation] If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Timeline

Published
November 3, 2026
Last Modified
November 3, 2026
First Seen
November 3, 2026

Related Vulnerabilities