- Last verified
- 31 Oct 2026
- CVE
- CVE-2026-111943
- Status
- Certificates are distrusted and being revoked. Self-managed systems need a trust store update.
What happened
On 17 October 2026 a researcher reported that the private keys of eight eMudhra subordinate CA certificates were weak. Some of the certificates were cross-signed by AAA Certificate Services. Google’s bulletin says the keys were generated with insufficient randomness. A remote attacker with network access could rebuild the private keys, forge TLS certificates that clients trust and intercept traffic.
The affected certificates are no longer trusted and are being revoked. Google says its own infrastructure is not compromised and that it sees no sign of exploitation of Google Cloud workloads. Browsers moved first, but a browser update does not reach a Linux server, a container image or a CLI that carries its own list of trusted CAs.
Who needs to act
Google lists the affected products, and the list is long: Google Cloud CLI, Cloud Shell, Compute Engine, Container-Optimized OS, GKE, Vertex AI, Colab Enterprise, App Engine, Cloud Run, Cloud Run functions, Cloud SQL, AlloyDB, Firestore and more. For managed services Google is rolling out fleet updates. You act where you manage the operating system, the image or the CA bundle.
| Where | What to do |
|---|---|
| Debian and Ubuntu hosts and images | Update the ca-certificates package. For Ubuntu follow USN-8944-1. |
| RHEL and compatible | Follow Red Hat bulletin RHSB-2026-012. |
| Windows | Install the latest Windows updates. |
| Container-Optimized OS on GKE or Compute Engine | Upgrade or restart nodes to a current release, or apply Google’s cos_ca_cert_mitigation tool. |
| Google Cloud CLI | Update to the latest release. |
| Your own images | Rebuild so they pull the updated CA package, then redeploy. |
| Runtimes with their own bundle | Update them. The 21 October Node.js security release includes an updated root certificate store. |
Check yourself
Google’s bulletin does not give a verification procedure, so use your vendor’s advisory. These commands help you see what a system still trusts and which versions you run:
# Debian and Ubuntu: package version and emSign entries
dpkg -l ca-certificates
ls /etc/ssl/certs | grep -i emsign
# Which Node.js are you on
node -v
What you should see depends on your operating system vendor’s decision. Follow their advisory, not a single filename.
Look beyond the OS
The easy mistake is to patch the servers and forget the places that ship their own bundle: language runtimes, Java keystores, Python packages that bundle certificates, CLI tools, build agents and base images that were not rebuilt. Ask for each one: does it use the system store or its own?
How we can help
We find every place a certificate bundle lives in your estate and put a process in place so the next CA incident takes hours, not weeks. Book a call from the button below.