eMudhra Trust Store Updates for Python, Node, Go, Rust, Electron, Bun

After the eMudhra weak key incident, most language runtimes shipped fixes between 19 and 21 October 2026: certifi 2026.10.19, pip 26.2.2, uv 0.13.4, Go 1.27.3 and 1.26.10, Node.js 22.23.4, 24.22.1 and 26.12.1, rustls-webpki 0.103.16 and Electron 44.9.1. Bun was still pending. Update each one, rebuild what embeds it, then test.

For what happened and how browsers responded, read our eMudhra CA key compromise explainer. This post stays inside your build. Versions come from the tracking site run by Mozilla's Dennis Jackson, cross-checked against each project's release notes where we could read them.

Fixed versions at a glance

For tickets: Go, RustSec, the rustup team and Chainguard reference CVE-2026-111943. The uv advisory has no CVE, and the Node.js notes we read do not tie any listed CVE to eMudhra.

Two kinds of fix: removing a root versus blocking intermediates

Not every project fixed this the same way, and the difference matters when you test.

Root removal. certifi, webpki-roots, Node.js (through NSS 3.131.1) and Bun's pending change drop the emSign ECC Root CA G3 from their bundled list. Mozilla describes the NSS update as a way to "remove the root certificate that signed the affected intermediates," aimed at applications that use Mozilla's root list but never receive Firefox's OneCRL revocation feed.

Intermediate blocking. Go's crypto/x509 and rustls-webpki 0.103.16 add a built-in denylist. The Go announcement says verification now filters out any chain containing the affected intermediates. The rustls-webpki release describes rejecting certificate paths that include "distrusted SPKIs," meaning specific public keys. The Node.js 22.23.4 notes also list a TLS commit that rejects chains containing blocked public keys; the 24.22.1 and 26.12.1 notes we read show the NSS update only.

Why both? Scott Helme reports that each of the eight eMudhra intermediates was also cross-signed by Sectigo's AAA Certificate Services root in May 2025. A client that only removes the eMudhra root could, in principle, still build a path through that cross-sign if it trusts the Sectigo root. The tracking site's manual workarounds for Debian, Ubuntu, Alpine, Fedora, macOS and others remove both roots from the system file, and it runs two test hosts: one for the direct chain and one for the AAA path. When we searched the certifi 2026.10.19 bundle file, we found neither the G3 ECC root nor an AAA Certificate Services entry. Other emSign roots (G1, C1 and C3 ECC) remain in certifi. Do not take our reading as proof for your environment. Test both hosts.

How each runtime chooses its roots

The single most useful thing to know is where each client gets its trust list. A host update fixes clients that read the OS file. It does nothing for clients that carry their own.

Python: certifi, requests, pip and uv

Python is really four separate trust decisions.

The standard library ssl module loads "default locations": per the Python docs, the CA and ROOT stores on Windows plus OpenSSL's build-time default paths everywhere. On a distro Python that is the distro bundle, so updating ca-certificates fixes it.

The requests library is different. Its documentation says it "uses certificates from the package certifi," so a fixed OS bundle does not help requests. Only a newer certifi does, or an explicit REQUESTS_CA_BUNDLE.

pip vendors its own copy of certifi. Its changelog for 24.2 says it uses "system certificates and certifi certificates" on Python 3.10 and newer. That is a union: if either source still trusts the root, pip trusts it. pip 26.2.2's only listed change is vendoring certifi 2026.10.19. The tracking site adds a workaround for the macOS built-in python3: point PIP_CERT at the fixed system file through sitecustomize.py.

uv uses bundled Mozilla roots by default, compiled into the uv binary. Its advisory says users are affected "if they use uv's bundled CA certificates, which are used by default." With --system-certs, uv hands verification to the operating system through rustls-platform-verifier, so the OS needs to be fixed instead. If you set SSL_CERT_FILE or SSL_CERT_DIR, uv's docs say those "override the default certificate source entirely," so the file you point at must be clean.

Check all four:

python3 -m pip show certifi | grep -i '^version'        # want 2026.10.19 or later
python3 -c "import certifi; print(certifi.where())"
grep -c "emSign ECC Root CA - G3" "$(python3 -m certifi)"  # want 0
python3 -m pip --version                                 # want 26.2.2 or later
python3 -c "from pip._vendor import certifi; print(certifi.__version__)"
python3 -c "import ssl; print(ssl.get_default_verify_paths())"
uv --version                                             # want 0.13.4 or later
grep -A1 '^name = "certifi"' uv.lock poetry.lock 2>/dev/null
grep -i '^certifi' requirements*.txt 2>/dev/null

certifi is usually transitive, pinned through requests, botocore or an SDK you never think about.

Node.js

Node.js compiles a snapshot of the Mozilla root list into the binary. The Node docs describe the bundled store as a snapshot fixed when that Node version is released, identical on all platforms. That is why the fix is a new Node release, not an OS update.

Two options change this. NODE_EXTRA_CA_CERTS adds certificates to the bundled set. --use-system-ca (or NODE_USE_SYSTEM_CA=1 on 24.6.0 and 22.19.0 or later) adds the OS store on top of the bundled one. Neither removes anything. The docs also say Node "does not support distrust/revocation of certificates from another source based on system settings." So turning on the system store does not cancel a stale bundled root. You need a fixed Node.

node -v      # want 22.23.4, 24.22.1, 26.12.1 or later on your line
node -e "const {X509Certificate}=require('crypto');const tls=require('tls');
console.log(tls.rootCertificates.map(p=>new X509Certificate(p).subject)
.filter(s=>/emSign ECC Root CA - G3/.test(s)).length)"   # want 0

Check every place Node lives: base image tags, CI runner images, version managers on laptops, and anything that embeds Node, such as Electron.

Go

Go reads the OS bundle on Linux and uses the system verifier on macOS and Windows; since Go 1.27, setting SSL_CERT_FILE or SSL_CERT_DIR disables those platform APIs, per the crypto/x509 docs.

The eMudhra fix is a denylist inside the standard library, in Go 1.27.3 and 1.26.10. Neither the announcement nor the Go issue says whether it also applies when Go uses the macOS or Windows verifier. Treat the OS update and the Go update as separate jobs.

Because Go links the standard library into each binary, upgrading the toolchain on a build machine changes nothing for binaries already built. Every Go program must be rebuilt, and every container it runs in must carry a fixed ca-certificates package.

go version                              # toolchain: want go1.27.3 or go1.26.10 or later
go version ./bin/                       # walks the directory and prints the toolchain of every binary
go version -m ./bin/api | head -1

Helme notes that common tools such as Terraform and kubectl are written in Go. You cannot rebuild those yourself; you need their vendors' next releases built with a fixed toolchain.

Rust: rustls, webpki-roots and rustup

Rust programs usually trust one of three things: webpki-roots or webpki-root-certs (a root list compiled into your binary), the OS store through rustls-native-certs, or the OS verifier through rustls-platform-verifier. The verifier itself is rustls-webpki.

The fix comes in two crates. webpki-roots and webpki-root-certs 1.0.10 remove the G3 ECC root. rustls-webpki 0.103.16 adds the public key denylist. RustSec's advisory says older versions may accept paths through the distrusted intermediates "only when the configured trust anchors allow such paths," which is exactly the case with an old root list. Update both.

cargo tree -i rustls-webpki             # want 0.103.16 or later
cargo tree -i webpki-roots              # want 1.0.10 or later
cargo tree -i webpki-root-certs
cargo update -p rustls-webpki -p webpki-roots -p webpki-root-certs
rustup --version                        # want 1.29.2 or later
rustup self update

If cargo tree shows more than one version of a crate, each copy must resolve to a fixed one. rustup 1.29.2 only bumps these two crates; rustup update also updates rustup itself.

Electron

An Electron app ships its own Chromium and its own Node.js inside the app bundle. The OS store, the system Node and the user's Chrome do not fix it.

The tracking site lists Electron 44.9.1, 43.8.1 and 42.11.16 as fixed, all released on 20 October. We could not find the change described in their release notes: the 43.8.1 and 42.11.16 notes list a window session fix and a fix so setCertificateVerifyProc applies to concurrent first requests, and the 44.9.1 notes were not available when we checked. Electron's releases site lists Node.js 24.22.0 and Chromium 152.0.7977.167 for 44.9.1, while Node's own NSS 3.131.1 update landed in 24.22.1 the next day. If your app makes HTTPS calls from the main process with Node APIs, test that path separately from the renderer.

npm ls electron
npx electron --version
# inside the app, log once at startup:
# console.log(process.versions.electron, process.versions.chrome, process.versions.node)

Upgrading Electron in package.json protects nobody until you build, sign and ship a release and users install it.

Bun

Bun compiles its root store into the runtime. PR 46159, merged on 20 October, regenerates that store and removes four emSign roots (G1, G3 ECC, C1 and C3 ECC), taking the bundle from 121 to 117 certificates. The PR page notes that Bun's native fetch uses the compiled-in store, so the change reaches users only through a Bun release. When we checked, the latest Bun release on GitHub was v1.4.3 from 10 October, and the tracking site still marked Bun as pending.

Comments on the PR show some projects pinning canary builds in the meantime. If you do that, test it like any other runtime change. Standalone executables made with bun build --compile embed the runtime, so they need a rebuild once a fixed release ships.

bun --version
bun -e "console.log(require('tls').rootCertificates.length)"   # 117 after the fix, per the PR

Walkthrough: one afternoon for a mixed estate

1. List the runtimes you actually run. Not the ones in your style guide. Pull them from lockfiles, Dockerfiles, CI images and SBOMs. Our post on SBOM-driven incident response covers doing this as a query instead of a grep marathon.

2. Bump the packages. One pull request per repo is fine:

# Python
uv lock --upgrade-package certifi            # or: pip install -U "certifi>=2026.10.19"
# Rust
cargo update -p rustls-webpki -p webpki-roots -p webpki-root-certs
# Node and Electron
npm install electron@44.9.1 --save-dev       # or the fixed release on your major line

3. Pin fixed runtimes in images and CI. Change the base tag to a fixed Node line, set the Go toolchain to 1.27.3 or 1.26.10 in go.mod with a toolchain line or your builder image, and update CI runner images.

4. Rebuild with fresh layers. docker build --pull --no-cache so the base image's ca-certificates package is current too. The parent post lists distro package versions.

5. Test inside the artifact, not on your laptop.

docker run --rm your-api:fixed python3 -c \
  "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/')"
docker run --rm your-api:fixed python3 -c \
  "import requests; requests.get('https://dv-g3b-aaa-emudhra.we-have-a-problem.com/')"
docker run --rm your-worker:fixed node -e \
  "fetch('https://dv-g3b-emudhra.we-have-a-problem.com/').then(()=>console.log('TRUSTED'),e=>console.log('rejected',e.cause?.code))"

A certificate error is the result you want. A 200 means that client still trusts the chain.

6. Redeploy and restart. Long-running processes loaded their trust store at startup. Node reads NODE_EXTRA_CA_CERTS only at launch, per its docs, and most clients cache roots in memory.

7. Record the result. Keep the versions and test output with the change ticket. Customers and auditors will ask.

Why rebuilding binaries and images matters

The pattern across every runtime above is the same: the trust decision is frozen into an artifact at build time.

• A container image holds the ca-certificates package, the certifi wheel and the Node binary that were current when it was built. A host patch never reaches inside.
• A Go binary carries the crypto/x509 code from the toolchain that compiled it.
• A Rust binary with webpki-roots carries its root list as compiled data.
• An Electron app carries a full Chromium and Node.js, delivered to user machines you do not control.
• uv and a compiled Bun executable carry their own stores.

Helme points out that the affected intermediates are valid until 2039, so anything you never rebuild could trust them that long. Cloudflare advises rebuilding affected images, then confirming whether applications need a reload, restart or redeploy. The same lesson came up in our container image supply chain incidents round-up and in finding every PHP runtime after PHP2Shell: the fix exists long before it is running.

Common mistakes and troubleshooting

• "The host is patched, so the app is fine." Only clients reading the OS file benefit. requests, uv, Node, Bun and Rust programs with webpki-roots do not.
• Turning on the system store to "pick up" the fix. In Node and pip the system store is added to the bundled one, so a stale bundle still trusts the root.
• Updating the Go toolchain and not rebuilding. go version ./bin/ will show the old toolchain in every binary you skipped.
• Setting SSL_CERT_FILE to a file you have not checked. uv and Go treat it as the whole trust source.
• A test that passes for the wrong reason. If the test host fails with a DNS error or timeout, you learned nothing. Look for a certificate verification error specifically, such as CERTIFICATE_VERIFY_FAILED in Python or a certificate error code in Node.
• Disabling verification when a partner breaks. Cloudflare specifically warns against clearing these errors by turning verification off. Ask the partner for a certificate from another hierarchy.
• Forgetting developer machines. The tracking site notes macOS /usr/bin/curl, git, python3 and the system /etc/ssl/cert.pem had not been updated by Apple when it last checked, and offers a workaround with a backup step.

What would have helped

Practices any team can use

Know your trust paths before you need them. For each service, write down which client library makes outbound TLS calls and which store it uses. The table above is a starting template. Cloudflare's point applies: an SDK often hands verification to an HTTP library, the language runtime, the operating system or a custom trust file, so the SDK version alone tells you little.

Treat CA bundles and runtimes as owned dependencies, with automated update PRs for certifi, webpki-roots, the Node line and the Go toolchain.

Rebuild on a schedule. Weekly image rebuilds, even with no code change, pick up fixed base layers and keep the redeploy path well practised.

Keep a standing test. Add the tracking site's test hosts, or your own negative test against a revoked chain, to a smoke test that runs from inside each deployed artifact.

Ship desktop apps with a working update channel. For Electron, the fix is only as fast as your release and auto-update cycle.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, across seven package ecosystems, and issues findings as SGZ advisories before they reach public CVE databases. It is built to find code flaws in packages. A CA generating weak keys during a ceremony is not a package code flaw, so this is not the kind of issue it hunts for, and Safeguard did not discover the eMudhra problem.

Gold Open Source at gold.safeguard.sh is free with no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a GitHub Action for CI gates. Gold Registry at registry.safeguard.sh is the paid side: hardened drop-in components and container images held to zero exploitable critical or high CVEs, built to SLSA L3+, signed with Sigstore and published with evidence pages; an artifact loses its badge if it regresses.

We are not saying Gold carried a fixed trust store before the upstream projects shipped one. The habit that helps in an incident like this is pulling patched, signed base images and components from a curated source, then rebuilding and redeploying quickly when upstream moves.

Where Safeguard fits

• Finding where each bundle lives. SBOM and dependency scanning covers repos, container images and SBOM files: safeguard scan --dir ., safeguard scan --image <name> or safeguard scan --sbom <file>, with JSON results under ./output. The platform shows which projects contain a given component and version, so "which images still have certifi below 2026.10.19" or "which repos pin webpki-roots below 1.0.10" is a lookup.
• Matching advisories. Vulnerability matching against vulnerability databases can flag issues with published identifiers, such as the rustls-webpki advisory, once they appear in the sources it matches against. A plain root removal with no advisory will not show up as a vulnerability, so use the component and version view for certifi and similar bundles. Reachability analysis helps you rank code-level findings but does not decide which trust store a TLS client uses.
• Holding the line. Policies and gates evaluated in the platform can block builds that still carry an outdated bundle version.
• Making the change. Autonomous remediation can open fix PRs for dependency bumps; it is off by default. The Safeguard CLI assistant can edit a lockfile or Dockerfile and run the rebuild and tests with your approval of each command, and safeguard exec runs a non-interactive turn for CI.

Where it does not help: it cannot improve a CA's key ceremony, cannot tell you whether a forged certificate was ever used, does not see trust stores on hosts, appliances or third-party binaries you never scan, and will not ship your Electron update to users. Nothing here would have prevented the incident itself.

FAQ

Which certifi version removes the eMudhra root?

certifi 2026.10.19, published to PyPI on 20 October. It has no release notes, but the bundle file no longer contains the emSign ECC Root CA G3 entry. Other emSign roots, such as G1, are still present because they are not part of this removal.

I updated certifi. Why does pip still matter?

pip vendors its own copy of certifi and, on Python 3.10 and newer, also trusts system certificates. pip 26.2.2 vendors certifi 2026.10.19. Upgrade pip in every image and virtual environment, since each one has its own copy.

Does turning on the system CA store in Node.js fix this?

No. It adds the OS store to Node's bundled roots and does not remove anything. Node's docs say it does not apply distrust from other sources. Upgrade to 22.23.4, 24.22.1 or 26.12.1 or later.

Do I need to rebuild Go programs if the server's OS is patched?

Yes. The Go fix is a denylist compiled into crypto/x509, so it only exists in binaries built with Go 1.27.3, 1.26.10 or later. The OS update fixes the root files Go reads on Linux, which is a separate layer.

Is Bun fixed?

Not in a release at the time of writing. The fix was merged into Bun's main branch on 20 October and the tracking site lists Bun as pending. Watch Bun's releases, then upgrade and rebuild compiled executables.

Is my Electron app fixed if users have updated Chrome?

No. Electron bundles its own Chromium and Node.js. Upgrade to 44.9.1, 43.8.1 or 42.11.16 or later per the tracking site, build and ship a new release, and confirm users receive it.

What is CVE-2026-111943?

It is the identifier Go, RustSec (RUSTSEC-2026-0382), the rustup team and Chainguard use for this issue. uv's advisory GHSA-hq85-5cpj-mr62 has no CVE. Some fixes, such as certifi, have no advisory at all, so do not rely on CVE matching alone.

To find every image and service still shipping an old bundle, download Safeguard and follow the CLI docs. For the wider month, see October 2026 security incidents and what would have helped.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding, asks before each command, edits package.json, then runs install and tests with your approval. For eMudhra you would ask the same assistant to bump certifi to 2026.10.19 in your lockfile or set your Dockerfile's Node base tag to a fixed line, then run the tests. It asks before every command and pushes nothing.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on your computer, picking a folder, and approving or denying each command and file edit until the upgrade is done and tests pass. Here the same flow could rebuild a Go service with the 1.27.3 toolchain and a fresh base image, one approval at a time.

Click through it at your own pace, or open it full screen.

The local runner demo shows setting up the runner on your own machine, approving it with its device code, then scanning from the terminal. After eMudhra, you would scan each rebuilt image to confirm the certifi, Node and ca-certificates versions it now contains.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• eMudhra incident tracking and test site (Dennis Jackson)
• Go: Go 1.27.3 and Go 1.26.10 security fix announcement
• Go issue 82345
• Go crypto/x509 package documentation
• Node.js v22.23.4 release
• Node.js v24.22.1 release
• Node.js v26.12.1 release
• Node.js command line options
• certifi 2026.10.19 release
• certifi 2026.10.19 on PyPI
• certifi 2026.10.19 cacert.pem
• pip changelog
• pip 26.2.2 release
• uv 0.13.4 release
• uv advisory GHSA-hq85-5cpj-mr62
• uv documentation: TLS certificates
• Python ssl module documentation
• Requests: CA certificates
• rustls-webpki 0.103.16 release
• webpki-roots 1.0.10 release
• RustSec RUSTSEC-2026-0382
• Rust blog: Announcing rustup 1.29.2
• Electron v44.9.1 release
• Electron v44.9.1 on the Electron releases site
• Electron v43.8.1 release
• Electron v42.11.16 release
• Bun PR 46159: update root certificates
• Bun releases
• Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates
• Cloudflare: eMudhra certificate compromise
• Scott Helme: Eight Bits of Trust

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.