eMudhra CA Compromise: Update Linux, Docker and Node.js

The eMudhra CA compromise affects Linux servers, containers and application runtimes that still trust eight compromised intermediate certificate-authority keys. Update your operating system’s ca-certificates package, rebuild affected container images, and update runtimes with their own certificate stores. Ubuntu has published fixed packages, Docker has issued specific Sandbox guidance, and Node.js users should move to 22.23.4, 24.22.1 or 26.12.1.

What happened in the eMudhra CA compromise?

A security researcher reported on 17 October 2026 that the private keys associated with eight eMudhra intermediate certificate authorities were compromised. The public incident report demonstrates control of the keys with signatures that can be verified against the certificates’ public keys.

The underlying problem is unusually serious: the CA generated the private keys incorrectly, making it possible to recover them from information in the public certificates. The affected certificates were created in April 2025, so the theoretical exposure existed before the October disclosure.

Mozilla received the report at 20:06 UTC on 17 October and completed a Firefox block through OneCRL by 22:59 UTC. The affected certificates were subsequently revoked, and Apple, Microsoft, Chrome, Linux distributions and language ecosystems began distributing their own protections.

The incident became public on 20 October. Vendor remediation continued afterward because not every TLS client consumes browser-style revocation lists. That gap is why Linux servers, old container images and runtimes with bundled certificate stores require separate attention.

Why does the certificate compromise matter?

A certificate authority sits inside the system used to decide whether an HTTPS server is really the service it claims to be. Possession of a trusted intermediate CA private key can allow an attacker to create a fraudulent certificate for a domain they do not control.

If an unpatched client accepts that certificate and the attacker can intercept or redirect the connection, the attacker may be able to impersonate the destination, read traffic or modify data in transit. Possible targets include API calls, software downloads, package repositories, identity services and automated build pipelines.

This does not mean every Linux server or website using HTTPS has already been breached. Red Hat identifies three necessary conditions: the client still trusts the affected chain, an attacker has the compromised key, and the attacker is in a position to intercept the TLS connection. The compromise creates a dangerous authentication capability; it does not remove the need for a network interception path.

Which systems are affected?

The useful question is not simply whether a machine runs Linux. Administrators must identify which trust store each application actually uses.

A successful browser test does not prove that curl, Git, a Node.js process or a container is protected. Conversely, testing the operating-system trust store does not prove that an application with an embedded CA bundle has been updated.

How to update Ubuntu and Debian systems

Ubuntu published USN-8944-1 and recommends applying the normal security update. On a supported Ubuntu release, update the package with:

sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg-query -W -f='${Version}n' ca-certificates

You can also install the complete available update set through your normal maintenance process:

sudo apt update
sudo apt upgrade

Ubuntu 20.04 and older releases receive the listed fix through Expanded Security Maintenance. Debian administrators should use Debian’s security repositories and verify their installed package against the advisory for the exact release rather than copying an Ubuntu version.

After updating the trust store, restart or reload long-running services that cache certificate data. Test the actual outbound connections used by the application. A package installation alone is not complete operational verification.

What should RHEL and Fedora administrators do?

Red Hat rates the incident Important and lists RHEL 6 through RHEL 10, related products and RHEL or UBI-based containers as potentially affected. Check the installed package first:

rpm -q ca-certificates
sudo dnf update ca-certificates

Package availability differs by product and lifecycle. Confirm the fixed erratum for the exact RHEL, Rocky Linux, AlmaLinux or Fedora release you operate. Red Hat also documents a blocklist mitigation for environments awaiting an updated package, but that mitigation distrusts entire roots and can break legitimate certificate chains. Use the vendor procedure only after evaluating that trade-off.

Do not manually delete random files from /etc/pki based on an unverified command copied from social media. Trust stores are generated from managed sources, and an incomplete manual edit can either fail to remove the affected trust or break unrelated services.

How to fix Docker containers and Sandboxes

Containers need special attention because patching the host does not necessarily alter the CA bundle inside an application image. Updating a running container also leaves the original image unchanged, allowing the vulnerable trust store to return at the next deployment.

For a normal Docker or Kubernetes workload:

1. Identify the base distribution and the certificate package used by the application.
2. Pull an updated base image from its trusted registry.
3. Rebuild the application image, ensuring an old cached certificate layer is not reused.
4. Deploy the new image by digest and replace every replica, job and scheduled workload that uses the old image.
5. Run the verification through the application’s actual TLS library.

docker pull ubuntu:24.04
docker build --pull --no-cache -t example/app:ca-fix-20261023 .
docker run --rm example/app:ca-fix-20261023 
  sh -c "dpkg-query -W ca-certificates || rpm -q ca-certificates"

Adapt the command to the image family and your controlled build process. A full no-cache build is useful for this emergency trust-store refresh, but production teams should still inspect every dependency and generated layer.

Docker’s separate Sandbox product uses template images. Docker says updating the sbx CLI alone does not update existing sandboxes. Its guidance is to recreate a sandbox with --pull always, or update ca-certificates inside an existing sandbox and restart applications that use the trust store.

If you operate Docker hosts, review our Docker installation guide for Ubuntu, but follow the current vendor security notice for this incident rather than relying on an older base-image tag.

Which Node.js versions contain the fix?

Node.js included its response to the eMudhra compromise in the 21 October security releases. Upgrade to one of these patch versions or later within a supported branch:

Those releases also fix unrelated Node.js vulnerabilities, including high-severity DNS, TLS and Brotli issues. The eMudhra response is therefore only one reason to install them.

Check both the runtime used interactively and the one inside services or containers:

node --version
node -p "process.execPath"
docker run --rm your-image node --version

CVE-2026-111943 is often mentioned in coverage of this incident, but the CVE record belongs to the Go standard library’s crypto/x509 denylist change. Red Hat separately tracks its ca-certificates work as CVE-2026-114406. Treat the compromise as a cross-ecosystem incident with product-specific tracking identifiers, not as one universal Node.js or Linux CVE.

How to verify that a client no longer trusts the keys

The incident researchers operate test hosts whose certificates chain through the compromised intermediates. Test the exact client or container you care about without using -k or any option that disables verification:

curl --max-time 10 https://dv-g3b-emudhra.we-have-a-problem.com/
curl --max-time 10 https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

A certificate validation error is the expected protected result. A successful HTTPS response means that the tested client still trusts the compromised intermediate chain. The researchers also provide “No CT” endpoints for clients that do not enforce Certificate Transparency.

This check tests only the TLS path used by that command. Repeat it inside the relevant container and, where possible, through the application’s own HTTP or TLS library. Do not conclude that an entire machine is protected because one browser or one curl binary rejected the chain.

What the updates do not prove

• A clean test now does not prove that the client was never exposed before the update.
• A browser block does not update certificate bundles embedded in applications or containers.
• A host package update does not rebuild existing images stored in a registry.
• Revocation does not protect clients that neither check revocation nor receive an updated trust store.
• The compromise alone is not evidence that an attacker intercepted your traffic.

As of 23 October 2026, the incident report says it is unknown whether attackers exploited the flawed key generation against non-browser clients. Cloudflare reported no active exploitation identified on its services. That is useful context, but it is not a reason to delay patching systems that still trust the keys.

Administrators responsible for sensitive outbound connections should review logs, proxy telemetry, certificate observations and dependency inventories. Certificate Transparency can help detect publicly logged fraudulent certificates, but clients that do not enforce CT are part of the concern in this incident.

Our assessment

The largest practical risk is not an up-to-date consumer browser. It is infrastructure that quietly carries its own trust decisions: old containers, CI runners, API clients, language runtimes, appliances and long-lived services that are rarely rebuilt.

The safest response is an inventory exercise, not a single command. Update the operating-system bundle, identify applications that embed their own certificates, rebuild immutable images, restart long-running processes and test the precise verification path used in production.

This incident also demonstrates why container and dependency maintenance belongs in a practical Linux server-hardening plan. A patched host cannot compensate for every stale trust store inside an application image.

Administrators already responding to the separate PHP2Shell vulnerabilities should keep the two incidents distinct. PHP2Shell requires PHP runtime updates, while eMudhra requires trust-store and runtime remediation. Our PHP2Shell update guide covers that independent emergency.

Frequently asked questions

What is the eMudhra CA compromise?

It is the compromise of private keys associated with eight eMudhra intermediate certificate authorities. The keys were generated incorrectly and can be recovered from public certificate information.

Does this break TLS encryption?

No. It undermines certificate-based authentication. A client that trusts a fraudulent certificate may connect securely to the wrong endpoint, allowing an attacker in a suitable network position to intercept or alter traffic.

Is CVE-2026-111943 the CVE for every affected system?

No. That CVE tracks Go’s crypto/x509 response. Other ecosystems use different identifiers or vendor advisories, and the underlying event is a CA key compromise rather than one universal software flaw.

Are fully updated Firefox and Chrome installations protected?

Mozilla and Chrome blocked the affected certificates rapidly. Keep automatic updates enabled, but remember that browser protection does not automatically cover command-line tools, servers or containers.

Does updating the Linux host fix Docker containers?

Not necessarily. A container normally uses the trust store inside its own image. Pull an updated base, rebuild the application image and replace running workloads.

Should I disable certificate verification if updates cause errors?

No. Disabling verification removes endpoint authentication. Investigate the certificate chain and apply the appropriate vendor update instead.

How do I know whether remediation worked?

Confirm the vendor-fixed package or runtime version and test the application’s actual TLS client against the incident researchers’ test endpoints. A certificate error is the expected protected result.

Sources

• Incident report and client verification tests
• Mozilla: response timeline and Firefox protections
• Cloudflare: impact, remediation and developer guidance
• Ubuntu USN-8944-1: fixed ca-certificates packages
• Red Hat RHSB-2026-012: affected products and mitigation
• Docker: Sandbox response to the eMudhra compromise
• Node.js: 21 October 2026 security releases
• CVE-2026-111943: Go crypto/x509 tracking record