CVE-2026-115714: Elastic Docker images: compromised eMudhra CAs enable TLS MITM
HIGHElastic'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.
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?
How severe is it?
What is the attack surface?
What should I do?
1 step1) 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?
Which compliance frameworks are affected?
This CVE is relevant to:
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
MITRE ATLAS Techniques
AML.T0010AI Supply Chain CompromiseCompliance Controls Affected
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:NTimeline
Related Vulnerabilities
CVE-2024-291210.0BentoML: RCE via insecure deserialization (CVSS 10)
Same attack type: Supply ChainCVE-2025-5952810.0Flowise: Unauthenticated RCE via MCP config injection
Same attack type: Supply ChainCVE-2023-376510.0MLflow: path traversal allows arbitrary file read
Same attack type: Data LeakageCVE-2025-512010.0smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Data LeakageGHSA-vvpj-8cmc-gx3910.0picklescan: security flaw enables exploitation
Same attack type: Supply Chain