← back

How Eight Tiny Numbers Exposed a Failure in Internet Trust

50 min readsecuritycryptographypkitlsecdsacertificate-authorityincident-analysis

On October 17, 2026, a security researcher discovered that eight private keys belonging to eMudhra, a certificate authority trusted by major browsers and operating systems, could be recovered from publicly available information. The keys were supposed to provide approximately 192 bits of security against classical attacks. Instead, each was a number smaller than 256.

One of them was literally 4.

The others were 56, 66, 115, 155, 156, 230, and 237.

These were not passwords protecting private keys or arbitrary certificate identifiers. They were the actual private values used in elliptic-curve cryptography, belonging to intermediate certificate authorities capable of signing certificates that other systems might trust.

A legitimate P-384 private key is selected from an enormous space containing roughly 2^384 possibilities. The affected keys were all below 256, so anyone with the corresponding public certificates could recover them by trying at most 255 positive candidate values.

The algorithms worked. The certificates had valid structures. Hardware security modules reportedly used during key generation met a recognized security standard. Yet the resulting keys were so weak that recovering them required almost no computational effort.

Mozilla independently reconstructed the keys on October 17. Browser vendors and downstream software maintainers moved quickly to block the affected intermediates. The response eventually expanded to removal of the emSign ECC Root CA - G3 root from trust stores, affecting approximately 30,000 legitimate certificates.

The story is about more than a key-generation bug. It demonstrates how cryptographic correctness, operational correctness and trust are separate properties—and how a failure in one can undermine the others.

Update — October 29, 2026: eMudhra has acknowledged that a script error produced the weak issuing keys, but has not yet published the exact code-level defect or its full root-cause analysis. The company has also decided to exit the global SSL/TLS certificate business after transitioning customers. Separately, eMudhra disclosed a long-running web-application-firewall configuration problem that blocked some common HTTP clients from its CRL, OCSP and certificate-repository endpoints. That second incident is related to revocation availability, not the cryptographic cause of the weak keys.

How HTTPS establishes trust

When a client connects to https://example.com, TLS (Transport Layer Security) establishes an authenticated, encrypted communication channel. Encryption is useful only if the client is communicating with the intended server.

Most public HTTPS certificates use the X.509 format, which represents public keys, identities, issuers, validity periods and digital signatures. Certificates are issued by certificate authorities (CAs), which verify identity information and sign certificates so clients can establish a trusted chain.

The broader system is called PKI: Public Key Infrastructure.

flowchart TD
    A["Trusted Root CA"] -->|Signs| B["Intermediate CA"]
    B -->|Signs| C["Website Certificate"]
    C -->|Presented during TLS handshake| D["Browser or API Client"]
    D --> E{"Certificate checks pass?"}
    E -->|Yes| F["Authenticated TLS connection"]
    E -->|No| G["Connection rejected"]

The root CA is a trust anchor distributed through browser or operating-system trust stores. An intermediate CA receives authority from a parent and can issue additional certificates within its constraints.

A browser validates the chain, signatures, domain name, validity dates, certificate extensions and applicable policies. But a valid signature does not prove that the CA followed a secure process when creating the signing key.

If an attacker obtains a website's private key, that website may be impersonated. If an attacker obtains an unconstrained intermediate CA's private key, they may be able to generate certificates for arbitrary websites. That makes an intermediate CA compromise substantially more dangerous than an ordinary server-key compromise.

Understanding P-384 and the mathematics of the failure

The affected keys used elliptic-curve cryptography (ECC). The curve was NIST P-384, also known as secp384r1, and the signature algorithm was ECDSA: Elliptic Curve Digital Signature Algorithm.

A private key is a secret integer, conventionally written as d. Its corresponding public key Q is produced by scalar multiplication of a known generator point G:

Q = dG

This is not ordinary integer multiplication; it involves elliptic-curve point operations. Calculating Q from d is efficient. Recovering a properly generated d from Q requires solving the elliptic-curve discrete logarithm problem, for which no practical general classical solution is known at this security level.

The normal search space is approximately:

2^384 ≈ 3.94 × 10^115

That is about 116 decimal digits' worth of possibilities. P-384 conventionally provides around 192 bits of security against generic classical attacks.

For these keys, none of that difficulty mattered. An investigator could calculate the public key for each small candidate integer and compare it with the public key in the certificate.

1 × G   → Does it match Q?
2 × G   → Does it match Q?
3 × G   → Does it match Q?
4 × G   → Match found.

For the key 4, the search ended after four candidates. The algorithm had not failed; the supposedly secret input was predictable.

A simplified key-recovery demonstration

The following Python snippet illustrates the basic comparison technique using the cryptography library. Use only certificates and keys you are authorized to examine.

from cryptography import x509
from cryptography.hazmat.primitives.asymmetric import ec

with open("intermediate.pem", "rb") as f:
    certificate = x509.load_pem_x509_certificate(f.read())

target = certificate.public_key().public_numbers()

for d in range(1, 256):
    candidate = ec.derive_private_key(d, ec.SECP384R1())
    if candidate.public_key().public_numbers() == target:
        print(f"Recovered private key: {d}")
        break

Each candidate scalar produces a deterministic public key. If it matches the certificate's public key, the candidate is the private scalar. The public-key information needed for this comparison is already present in the certificate.

Scott Helme independently reproduced the recovery and published these values:

Intermediate certificate authority Purpose Private scalar
EM DV TLS CA - G3B TLS 156
EM DV TLS CA - G3C TLS 230
EM EV TLS CA - G3B TLS 115
EM EV TLS CA - G3C TLS 56
EM OV TLS CA - G3B TLS 155
EM OV TLS CA - G3C TLS 4
EM OV CS CA - G3B Code signing 66
EM OV CS CA - G3C Code signing 237

The six TLS intermediates covered domain-validated (DV), organization-validated (OV) and extended-validation (EV) certificates. The remaining two were intended for code signing (CS), which helps establish software publisher identity and whether signed code has changed.

ECDSA also uses a temporary secret value called a nonce for individual signatures. Predictable or repeated ECDSA nonces can reveal signing keys in other attacks, but that was not the issue here: the long-lived CA private keys themselves were weak.

Discovery and response

The researcher, identified as Wayne, examined certificate authority certificates sourced from the Common CA Database (CCADB), which browser root programs use to track publicly trusted CAs and their subordinate certificates.

After recovering the keys, Wayne signed the message:

We have a problem here - Wayne

The signatures provided proof of control: anyone with the corresponding public certificate could verify that the signer possessed the matching private key. The findings were reported to browser root programs and eMudhra on October 17, 2026. Mozilla independently reconstructed the keys later that day.

Date Event
April 30, 2025 The eight affected intermediate CA key pairs were created during a key-generation ceremony.
October 17, 2026 The weak keys were reported to root programs and eMudhra; Mozilla independently recovered them.
October 17 Chrome and Mozilla deployed emergency blocking measures.
October 18 eMudhra revoked all eight affected intermediates.
October 20–21 Browser and software maintainers published or deployed further mitigations; eMudhra described a second weak key set created during a wrap/unwrap step.
October 21 Node.js 22.23.4, 24.22.1 and 26.12.1 security releases included updated CA data; 26.12.1 also added an explicit check for the compromised public keys.
October 22–23 eMudhra's board announced a decision to withdraw from the global SSL/TLS certificate business; Bun 1.4.4 shipped and its security advisory documented root removal and explicit key blocking.
October 25 A public Bugzilla report documented that common HTTP client User-Agent strings were being blocked at eMudhra's CRL, OCSP and repository endpoints. Researchers also reported more than 107,000 CT-logged certificates signed using six recovered keys after disclosure, mostly proof-of-concept certificates.
October 26 eMudhra's leadership explicitly acknowledged a script error as the cause of the weak issuing keys. It also says it removed the WAF User-Agent filter and commissioned an independent review of the key-generation incident.
October 27 Chrome's previously announced target date for removal of the G3 root from Chrome Root Store devices passed; the Google announcement described the planned rollout but did not publish a device-by-device completion count.
October 28 eMudhra updated its incident tracker: the roughly 30,800 certificates in the affected US customer ecosystem were using an alternative G1 RSA-root issuance path while eMudhra discussed a longer-term transition with other TLS providers. Node.js 24.22.2 and 26.13.0 were also released as later general releases, not as new incident-specific advisories.
October 29 eMudhra published a full incident report for the separate WAF/revocation-endpoint issue, identifying a vendor-configured filter and monitoring that failed to exercise blocked User-Agent types. A third-party follow-up continued to report intermittent endpoint timeouts.

The keys had existed since April 2025, more than seventeen months before discovery. Chrome said its pre-blocking CT review found no TLS certificates chaining to the six compromised TLS intermediates. Subsequent CT entries signed using the recovered keys included large numbers of proof-of-concept certificates; those entries do not by themselves prove real-world victimization or successful use against clients. Because the keys were recoverable from public certificates, an attacker would not have needed to steal them from eMudhra's infrastructure.

Why cross-signing complicated the response

The affected intermediates also had certificates cross-signed by Sectigo under the AAA Certificate Services hierarchy, historically associated with Comodo.

Cross-signing allows the same public key to participate in multiple certificate chains. The issuer, signature and serial number can differ while the underlying intermediate public key remains the same.

flowchart TD
    A["eMudhra trust hierarchy"] --> B["eMudhra-issued intermediate"]
    C["Sectigo AAA hierarchy"] --> D["Sectigo cross-signed intermediate"]
    B --> E["Same compromised public key"]
    D --> E
    E --> F["Potentially forged end-entity certificate"]
    F --> G["TLS client"]

Cross-signing does not create a new private key. If a client blocks only one certificate by issuer and serial number, it might still accept another certificate containing the same compromised key.

Chrome's response included blocking the affected Subject Public Key Info (SPKI) hashes. SPKI identifies the public key and its algorithm, so blocking by key identity can cover multiple certificates sharing that key. Sectigo also revoked its affected cross-signed certificates.

How could a professional CA generate such weak keys?

The keys were created during a Key Generation Ceremony (KGC) on April 30, 2025. Such ceremonies control the creation and provisioning of sensitive keys and may involve multiple operators, approved procedures, specialized hardware, audit records and independent checks.

eMudhra said the ceremony used Utimaco hardware security modules (HSMs), reportedly compliant with FIPS 140-2 Level 3. An HSM is a specialized device for generating, storing and using cryptographic keys while enforcing access controls and protecting sensitive operations. FIPS 140-2 defines security requirements for cryptographic modules.

The public evidence does not establish that the HSM's random-number generator was faulty. eMudhra's explanation points instead to the ceremony procedure, script and key-selection workflow.

According to the explanation in Mozilla Bug 2083449, the ceremony initially generated the expected strong ECC keys. The team then changed its usual steps to test key wrapping and unwrapping for keys intended for use in overseas data centers. Key wrapping protects a key—typically by encrypting it under a separate key-encryption key—for storage or transfer; unwrapping is the corresponding recovery or import operation.

A script flaw reportedly caused an additional, weak set of ECC keys to be created. The labels of the strong and weak keys looked similar, so staff selected the weak keys when creating Certificate Signing Requests (CSRs).

A CSR contains a public key and identifying information that a parent CA uses when issuing a certificate. The parent signs the supplied public key; it generally cannot infer whether the private scalar was generated with adequate entropy merely from the CSR.

The result was that eMudhra signed certificates containing the weak public keys. CSRs were also sent to Sectigo for cross-signing.

flowchart TD
    A["April 2025 key ceremony"] --> B["Strong ECC key pairs generated"]
    B --> C["Additional wrap/unwrap test"]
    C --> D["Script reportedly creates weak key pairs"]
    D --> E["Similar key labels"]
    E --> F["Wrong keys selected for CSRs"]
    F --> G["Certificates signed"]
    F --> H["CSRs cross-signed by Sectigo"]
    G --> I["Weak keys enter trusted PKI"]
    H --> I

On October 26, eMudhra's leadership publicly acknowledged that a script error resulted in issuing CAs with weak keys. That is a meaningful update from the earlier preliminary account, but it is not yet the full technical root cause. As of October 29, the specific faulty code, the precise data path that created the second key set, and the controls that should have caught the mismatch had not been published in a public root-cause report. eMudhra says it will publish that report through CCADB and has commissioned an independent expert review. The weak-key outcome is proven; the code-level explanation and remediation evidence remain outstanding.

The failure appears to involve a dangerous interaction between scripts, key identity and human procedure. An HSM cannot guarantee that the correct output from a multi-step process is selected and certified.

The warning that appeared a year earlier

Mozilla's investigation uncovered an issue dating back to May 2025: Certificate Revocation Lists (CRLs) published for the affected TLS intermediates contained invalid signatures.

A CRL is a CA-signed document listing revoked certificates. Its signature should verify using the public key associated with the issuing CA. Here, verification failed.

eMudhra explained that the original CRLs had been signed using the intended strong keys, while the publicly issued intermediate certificates contained the weak public keys. The CRLs were subsequently signed again using the weak keys.

This suggests that the key-selection mismatch had already produced an observable operational failure long before the public compromise report. An invalid signature is not necessarily evidence of compromise, but it is evidence that an assumption about identities, inputs, outputs or signing operations is wrong. That should trigger investigation beyond simply repairing the failing artifact.

Historical context: Mozilla's 2018 root-inclusion discussion

The current incident is not the first time eMudhra's emSign roots have been discussed in Mozilla's public security-policy forum. In an October 11, 2018 thread requesting inclusion of four emSign roots, Wayne Thayer reviewed the then-current Certificate Policy/Certification Practice Statement (CP/CPS) and identified several places where the documentation needed clarification or correction. Among the issues discussed were how external issuing CAs were described, whether pre-issuance linting was implemented, and whether the CP/CPS clearly prohibited the CA from generating TLS subscriber key pairs. The thread records that some wording was subsequently corrected.

That discussion is useful historical context for how public root-program review scrutinizes a CA's documented practices. It is not evidence that Mozilla knew about, or that the 2025 key-generation ceremony contained, the flaw discovered in October 2026. The 2018 discussion concerned root inclusion and policy documentation; it does not identify the weak intermediate keys or establish a causal connection to the present incident.

Source: Mozilla dev-security-policy: “Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3” (October 11, 2018).

What could an attacker do with the recovered keys?

The clearest threat was TLS server impersonation.

Suppose an application connects to api.example.com. During the TLS handshake, the server presents a certificate. A client verifies the chain and domain name before proceeding.

An attacker with a compromised intermediate private key could create a separate server key pair and produce a certificate claiming to represent api.example.com. If the attacker could redirect or intercept the connection, a vulnerable client might accept the fraudulent certificate because its signature was valid and the chain appeared to terminate at a trusted root.

The attacker would then control the TLS endpoint and might receive credentials, bearer tokens or API requests, or proxy and modify traffic between the victim and the real service.

This does not mean that a CA signing key automatically decrypts previously recorded TLS 1.3 traffic. Modern TLS commonly uses ephemeral key agreement, which provides forward secrecy. The compromised CA key primarily enables impersonation and unauthorized certificate issuance.

Scott Helme demonstrated the issue in a controlled environment by generating a certificate claiming to identify api.stripe.com. The test did not demonstrate a compromise of Stripe; it showed that a vulnerable TLS client could accept a counterfeit identity under the right network conditions.

The distinction between capability and confirmed exploitation matters. The attack was possible under certain conditions, but no confirmed real-world exploitation had been reported at the article's cutoff.

Why browsers were largely protected: Certificate Transparency

Certificate Transparency (CT) makes publicly trusted TLS certificate issuance visible through public, append-only logs.

When a certificate or precertificate is submitted to a CT log, the log can provide a Signed Certificate Timestamp (SCT), cryptographic evidence that the certificate has been submitted for logging. Browsers such as Chrome enforce CT requirements for applicable publicly trusted certificates. A certificate that fails those requirements may be rejected even if its ordinary signature and trust chain are valid.

sequenceDiagram
    participant CA as Certificate Issuer
    participant CT as Public CT Logs
    participant S as Website
    participant B as Browser

    CA->>CT: Submit certificate or precertificate
    CT-->>CA: Return signed timestamp evidence
    CA->>S: Issue certificate with CT evidence
    S->>B: Present certificate during TLS
    B->>B: Validate chain and hostname
    B->>B: Validate applicable CT requirements
    B-->>S: Accept or reject connection

Google reported that no TLS certificates chaining to the six compromised intermediates appeared in CT logs before Chrome's emergency blocking action. This is reassuring for CT-enforcing browsers.

An attacker could theoretically create a forged certificate privately, but without acceptable CT evidence it would not satisfy Chrome's normal public TLS policies. Other browsers enforce CT for applicable certificates too, although details vary.

CT does not prevent weak keys from being generated, repair a compromised CA, or identify who possesses a private key. It adds another condition for trusting a certificate, making secret, unlogged issuance harder to exploit against protected clients.

There is an important post-disclosure caveat. In comment 44 of Mozilla Bug 2083449, researcher Dennis Jackson reported that 107,107 certificates signed with six of the recovered keys were logged in two CT logs between October 20 and 21. The report says 106,050 were proof-of-concept certificates whose only Subject Alternative Name was google.com; examples also included emsign.filippo.io and precertificates for emudhra.salesforce.com. These entries demonstrate that recovered keys were used to sign and log certificates after disclosure. They do not establish that 107,107 real-world attacks occurred, that every certificate was accepted by clients, or that any particular user was successfully impersonated. Google separately said no TLS certificates chaining to the six affected intermediates were in CT before Chrome's emergency block.

The protection is less consistent outside mainstream browsers. Enterprise policies, custom configurations and differences in platform-level enforcement matter; Android applications do not all enforce CT in the same way as Chrome.

The forgotten part of HTTPS: non-browser clients

Browsers are only a subset of software that makes HTTPS connections. Servers talk to servers, CI/CD pipelines download dependencies, package managers retrieve software, containers fetch configuration, IoT devices contact APIs and desktop applications retrieve updates.

These clients may validate signatures, hostnames and trusted roots without enforcing Certificate Transparency. Many do not check intermediate revocation by default.

flowchart TD
    A["Application opens HTTPS connection"] --> B["Verify hostname"]
    B --> C["Validate signature chain"]
    C --> D["Check trusted root"]
    D --> E["Check dates and constraints"]
    E --> F{"Check CT and revocation?"}
    F -->|No| G["Potentially accepts compromised chain"]
    F -->|Yes| H["Apply additional security policies"]
    H --> I["Accept or reject"]

A CI runner might download a dependency while holding cloud credentials or package-registry tokens. A backend service might exchange OAuth tokens over HTTPS. A device updater might retrieve executable code from a remote server.

If an attacker can impersonate the destination and the client accepts the fraudulent certificate, exposure can extend beyond the immediate connection.

Updating Chrome does not automatically protect a Go service. Updating the system CA store may not protect a statically linked application with its own trust bundle. The security boundary follows the actual verifier used by each program.

Revocation is not one universal mechanism

Certificate authorities can revoke certificates, but distributing and enforcing revocation is a distributed-systems problem.

Mechanism What it does
CRL — Certificate Revocation List Publishes signed lists of revoked certificates
OCSP — Online Certificate Status Protocol Provides certificate status responses
OCSP stapling Lets a TLS server supply a signed status response
OneCRL Distributes Mozilla-managed revocation information
CRLSet Distributes Chrome's compact revocation blocklist
CRLite Enables efficient distribution of large-scale revocation information

These mechanisms differ in coverage, freshness, availability requirements and client support.

Mozilla used OneCRL to distribute emergency revocations to Firefox installations on October 17. Chrome used CRLSet to block compromised intermediate public-key hashes, covering original and cross-signed certificates. eMudhra revoked the eight affected intermediates on October 18 with the reason cACompromise; Sectigo separately revoked its cross-signed certificates.

Clients that do not consume applicable revocation information might continue accepting a certificate while its root remains trusted. That is one reason the response expanded to root removal.

A separate failure in access to revocation services

On October 25, researchers reported that eMudhra's HTTP revocation and repository endpoints returned 403 Forbidden when requests used common User-Agent strings identifying curl, Wget, Python's urllib, or libwww-perl. The filter affected CRL, OCSP and CA-certificate repository paths, including paths relevant to the newly published cACompromise revocations. Requests with other User-Agent strings could succeed. HTTPS access was reported as unaffected.

In its October 29 incident report in Mozilla Bugzilla 2085612, eMudhra said a generic, vendor-configured web application firewall profile had been applied to those hosts on September 28, 2022. It was intended to block bots and scanners, but it was applied to every path without excluding the endpoints that software uses to retrieve revocation and certificate data. eMudhra's monitoring used a single User-Agent that did not trigger the filter, so the problem went undetected. The company says it removed the filter from all seven listed hostnames at 10:32 UTC on October 26 and retested the published URLs with multiple common clients.

The report describes the incident as affecting zero certificates, because the certificates themselves were not defective and the CRLs/OCSP responses were produced correctly. That metric should not be confused with the availability impact: the third-party evidence in the same Bugzilla thread says common clients could not retrieve the affected revocation information during the filter period, including for roughly eight days after the compromised intermediates were revoked. The reporter also documented intermittent CRL and OCSP timeouts in tests after the filter was removed. Those later tests do not prove a continuing universal outage, but they mean filter removal and dependable endpoint availability are separate questions. There is also a discrepancy over scope: eMudhra's report lists crl-c.emsign.com and ocsp-c.emsign.com among the seven affected hostnames, while the third-party measurements say those hosts were not filtered in its tests and ask for per-host start/end times. As of October 29, eMudhra had published its report, while follow-up questions about timeouts, refused-request counts, host coverage and impact remained in the public thread.

This is a distinct operational incident, not the root cause of the weak ECC keys. It reinforces the same broader lesson: publishing revocation data is not enough if routine client software cannot reliably retrieve it, and monitoring must test the same access paths and client behaviours that relying parties use.

Why an entire root CA was removed

Mozilla and Google decided to remove emSign ECC Root CA - G3 from their trusted root stores. This was broader than blocking the eight weak keys.

The incident did not establish that the root private key itself was compromised. eMudhra said the root keys remained secure. Nevertheless, trust in a root CA depends on confidence in the organization's key generation, issuance, auditing, lifecycle management and incident response.

Removing the root also protects software that does not consume emergency intermediate revocations but does update its trusted roots. The cost is that legitimate certificates issued under the same hierarchy may stop working.

eMudhra estimated that approximately 30,000 certificates would need migration; about 97% had been issued through ACME, the Automatic Certificate Management Environment protocol used to automate certificate issuance and renewal. These were not 30,000 certificates known to have been forged. They were legitimate certificates affected by a broader trust-store decision.

Google announced that removal of the G3 root was expected to reach Chrome Root Store devices on October 27, 2026. The announcement established a target date; it did not provide a device-by-device rollout count. Site operators relying on this hierarchy needed certificates chaining to another trusted hierarchy. eMudhra's October 28 update says the roughly 30,800 certificates in the affected US customer ecosystem were using an alternative issuance path through its G1 RSA root. The company has asked browser/root-store programs for time to complete an orderly transition and says it is in advanced discussions with other TLS providers.

On October 22, eMudhra's board announced that the company would voluntarily withdraw from the global SSL/TLS certificate business. The announcement says its G1 RSA roots will continue to serve customers until the transition is complete, and that replacement certificates from partners will be provided at no cost. This is a business-exit decision, not a declaration that the G1 root itself has been distrusted; however, questions about the G1 hierarchy and related revocation/signing history were still being raised in Mozilla's public discussion. Do not assume the G1 hierarchy is compromised based on those questions alone.

What Chrome changed after the incident

Chrome's public response also exposed a gap in how CA certificates were screened. In comment 44 of Mozilla Bug 2083449, the Chrome Root Program said its standard linting workflow used pkimetal, integrating badkeys, zlint and related tools. Those tools did not check the specific small-scalar and pairwise-difference weaknesses that made these P-384 keys recoverable. Google's paranoid_crypto pipeline did perform deeper checks, but before this incident its relevant ingestion path covered certificates submitted to Chrome's CT logs; CA certificates disclosed only through CCADB and not otherwise ingested were outside that pipeline.

Chrome said it had expanded recurring paranoid_crypto assessments to cover certificates disclosed through CCADB, in addition to CT and certificates observed in the wild, and had added the checks to its relevant workflows. Chrome reported finding no other weak CA keys in the reviewed scope. It also said it was evaluating continuous checks of CA signatures, including CRLs, and remote key-attestation requirements.

The proposed CCADB-Tools issue #185 explores pre-import cryptographic screening of root and intermediate certificates. As of October 29, it remained an open proposal rather than a deployed CCADB gate. Chrome said it intended to pursue automated screening at disclosure time and recurring reassessment of the existing trust boundary. This is a defence-in-depth improvement, not a retroactive explanation for the eMudhra script defect.

What developers and administrators should update

Certificate trust is distributed across layers. Some applications rely on operating-system CA stores; others use Mozilla-derived bundles or ship certificates with their runtime. Still others compile trust logic into standalone executables.

The following incident-relevant fixes and releases were verified by October 29, 2026:

Component Remediated version or status
Firefox 158.0.1
Firefox ESR 115.43.1 / 153.5.1
NSS 3.131.1
Go 1.27.3 / 1.26.10
Python certifi 2026.10.19
pip 26.2.2
uv 0.13.4
Rust rustls-webpki 0.103.16
Rust webpki-roots 1.0.10
Electron 44.9.1 / 43.8.1 / 42.11.16
Node.js Incident-specific CA fix first included in 22.23.4 / 24.22.1 / 26.12.1 (October 21); later releases available by October 29 were 22.23.4 / 24.22.2 / 26.13.0
Bun 1.4.4 (released October 22; advisory published October 23)

NSS (Network Security Services) supplies cryptographic and certificate functionality used by Firefox and other software. Python's certifi package distributes a Mozilla-derived CA bundle; libraries such as requests commonly use it.

Go uses its own X.509 parsing and validation implementation, while certificate verification may also interact with the platform depending on environment. Because Go applications are often compiled into binaries, existing deployments may require rebuilding and redeploying after a fixed Go release.

Node.js may use bundled CA data, operating-system stores, additional CA files or native modules depending on configuration. The October 21 security releases—22.23.4, 24.22.1 and 26.12.1—updated the bundled CA data to NSS 3.131.1; 26.12.1 also added an explicit check to reject chains containing the compromised public keys. As of October 29, the newer available releases were 24.22.2 and 26.13.0, while 22.23.4 remained the latest listed 22.x release. The October 28 Node.js releases were general updates, not separate eMudhra-specific advisories; use the latest patch in the branch you deploy. Consult the official October 21 security release notes and Node.js release announcements.

On Ubuntu and Debian, administrators can update the distribution CA package:

sudo apt update
sudo apt install --only-upgrade ca-certificates
sudo update-ca-certificates

Python environments using certifi can be updated with:

python3 -m pip install --upgrade certifi

A useful practical test is available from the incident research site:

curl -v https://dv-g3b-emudhra.we-have-a-problem.com/

A cross-signed-chain test is also available:

curl -v https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

These endpoints deliberately present chains corresponding to affected keys. A certificate-validation failure is the desired outcome. A normally verified successful connection means that particular client accepted the tested chain. Do not use --insecure, which disables the check being evaluated.

One platform-specific issue concerns macOS. Although Apple's platform-level mitigations were reported deployed, the built-in /usr/bin/curl was reported to continue using /etc/ssl/cert.pem, an outdated CA bundle that did not necessarily reflect those protections.

This illustrates why saying “macOS is patched” does not necessarily describe every application's security state. Application owners should inventory certificate-verification paths, update trust stores, rebuild affected binaries or images, and test the actual component that makes the HTTPS request.

Update: what is confirmed, and what remains unanswered

Status as of October 29, 2026: the weak-key failure and a script error are confirmed; the precise code-level defect remains unpublished.

In Mozilla Bugzilla 2083449, eMudhra first described a key wrap/unwrap step that produced a second weak set of keys during the April 30, 2025 ceremony. On October 26, its leadership made the statement more direct: “A script error resulted in issuing CA's with weak keys.” eMudhra apologised, said it would publish a full root-cause analysis through CCADB, and announced that it had commissioned an independent expert to review the incident and the procedures and controls involved. The exact script defect, the sequence that produced the weak values, and evidence showing how the controls failed have not yet been made public.

The public Bugzilla discussion continued after the earlier comment 39. Chrome's October 25 response described why its existing monitoring had missed these dormant CA certificates: standard linting did not check the small P-384 private scalars or pairwise EC key differences involved here, and the paranoid_crypto pipeline had been focused on certificates entering CT logs rather than CA certificates disclosed only through CCADB. Chrome said it had expanded recurring checks to CCADB-disclosed CA certificates and incorporated the additional checks into relevant workflows. The proposed automated pre-import gate in CCADB-Tools issue #185 remained under discussion, not deployed, as of October 29.

There is also evidence of the recovered keys being used to sign certificates after the issue was disclosed. Dennis Jackson's Bugzilla comment 44 reported 107,107 CT-logged certificates signed with six of the eight keys between October 20 and 21, most of them proof-of-concept certificates. This is distinct from eMudhra's claim that it did not issue end-entity certificates itself. The CT entries establish post-disclosure signing activity; they do not prove 107,107 real-world attacks or successful impersonation of 107,107 users.

The separate WAF incident described above is also significant. On October 29, eMudhra published a full report in Bugzilla 2085612, acknowledging that common HTTP clients had been blocked by a generic WAF profile since September 2022 and that its monitoring did not use the affected User-Agent strings. It says the filter was removed on October 26. Third-party follow-up evidence still raised questions about intermittent timeouts after removal. This is not evidence that the same script caused both problems; it is another documented failure in operational controls and monitoring around the trust infrastructure.

The company also announced on October 22 that its board had decided to withdraw from the global SSL/TLS certificate business. Its October 28 status update said the affected US customer ecosystem was using an alternative issuance path through the G1 RSA root while eMudhra worked with browser/root-store programs and other TLS providers on a longer-term transition. The company says it will continue to support G1 certificates until the transition is complete. Questions about the G1 hierarchy and the prior CRL-signature mismatch were still being discussed publicly; they should be treated as unresolved questions, not proof that G1 is compromised.

The primary cryptographic facts are settled: all eight private scalars were recoverable, and multiple researchers independently verified the results. The script error is now acknowledged by eMudhra. The exact implementation-level root cause, the complete corrective-action evidence, and the full independent review are still outstanding in public disclosures. We also cannot conclude that no one exploited the weak keys before October 17 merely because eMudhra says it has no evidence of prior exploitation or because CT-enforcing browsers had stronger controls.

Nor should the incident be treated as evidence that all eMudhra keys, all Utimaco HSMs or elliptic-curve cryptography are defective. The published findings concern a defined set of keys and the associated ceremony and assurance controls. The relevant lesson is to distinguish proven cryptographic facts, the CA's own statements, third-party measurements and unresolved hypotheses.

The engineering problem underneath the cryptography

What interests me most is not just that somebody discovered a private key equal to 4. It is the number of individually reasonable components that apparently worked while the overall system produced a catastrophic result.

The ceremony used specialized security hardware. Operators followed an approved, if modified, procedure. The parent CA signed formally constructed requests. Sectigo cross-signed those requests. The certificates contained valid public keys and signatures.

Each component could appear correct in isolation. The failure existed in the relationship between them.

The script produced or selected unintended key material. The identifiers used by operators did not adequately distinguish that material from the intended keys. The CSR process accepted the selection. Certificate issuance turned those keys into publicly trusted cryptographic identities.

A mismatch between CRL signatures and certificate public keys was also an observable operational failure and an opportunity to examine the key lifecycle.

This is the sort of failure production engineering teaches us to look for. Correct output from a function does not necessarily mean the right function was called. A successful database transaction does not prove that the correct record was modified. A passed authentication check does not prove that the authorization context was correctly propagated. And a mathematically valid digital signature does not prove that the intended key was used.

A secure key-generation workflow needs more than secure random-number generation. It needs verifiable invariants connecting the key, its identifier, its approved purpose, the CSR, the signed certificate and every subsequent signing operation.

Checks that could help include verifying that the intended public key matches the generated CSR, flagging known weak-key classes where feasible, and independently comparing key identities at multiple ceremony stages. For HSM-protected keys that cannot be exported, assurance can also involve ceremony attestations, generation logs, device controls, constrained key usage, test signatures and verified public-key fingerprints.

None of these individually guarantees security. Together, they reduce the likelihood that a single script error or mistaken label silently crosses every boundary.

The industry's response offers a related lesson. Certificate Transparency helped protect mainstream browsers. Emergency revocation systems acted quickly once the keys were reported. But applications outside those ecosystems remained dependent on updates to operating systems, libraries, compiled binaries and embedded devices.

The security properties of the same certificate therefore depended on which client encountered it. That is a distributed trust problem, not simply a cryptography problem.

The decision to distrust the entire root made the consequences visible far beyond the original eight intermediates. Thousands of legitimate certificates needed migration because confidence in part of the certificate authority's operational process had been lost.

A certificate authority's product is ultimately trust. Its most important guarantee is not that it can produce a valid signature, but that its signatures reliably represent an identity verified and authorized through a controlled process.

In this incident, the mathematics of the signatures remained correct while that guarantee failed.

The private key 4 will probably remain the memorable detail. The more useful lesson is that strong cryptography cannot compensate for a system that fails to verify what it has actually created, selected and trusted.

References

This analysis reflects public disclosures and technical investigations available as of October 29, 2026. The references distinguish official statements from community-reported evidence and open questions.

  1. Mozilla Bug 2083449 — eMudhra private-key compromise — original report, key recovery, eMudhra's comments, Chrome's monitoring explanation, and open root-cause questions.
  2. Google Chrome Security — Protecting Chrome and Android Users — SPKI blocking, CT analysis, and planned G3 root removal.
  3. eMudhra's official incident statement — updates through October 28, including the script-error admission and customer-transition status.
  4. eMudhra — decision to exit the global SSL/TLS certificate business — October 22 board decision and transition commitment.
  5. Mozilla Bug 2085612 — access to CRLs blocked for certain User-Agent headers — eMudhra's October 29 incident report, WAF root cause, fix timeline and third-party follow-up measurements.
  6. Mozilla CCADB-Tools issue #185 — proposed pre-import cryptographic screening — proposal for automated checks on CA certificates submitted to CCADB.
  7. Scott Helme — Eight Bits of Trust — independent recovery of the private scalars and TLS impersonation tests.
  8. eMudhra Intermediate CA Compromise tracker — testing endpoints and downstream remediation tracker maintained by Dennis Jackson.
  9. Bun security advisory GHSA-26q8-h657-pf84 and Bun v1.4.4 release — removal of affected roots and explicit blocking of chains containing the eight compromised public keys.
  10. Node.js October 2026 security releases — incident-specific CA-data updates in versions 22.23.4, 24.22.1 and 26.12.1.
  11. Node.js release announcements — later general releases available as of October 29, including 24.22.2 and 26.13.0.
  12. Mozilla dev-security-policy — 2018 emSign root-inclusion discussion — historical discussion of emSign's root inclusion and CP/CPS documentation; not evidence of the 2026 key-generation flaw.
  13. CERT-In advisory on the eMudhra intermediate CA compromise — Indian government advisory distinguishing the global TLS incident from eMudhra's Indian DSC/eSign services.

Article updated October 29, 2026. The weak keys and a script error are confirmed; the exact code-level root cause has not yet been published. The separate WAF filtering incident has a published report and a stated fix date, but third-party tests continued to raise endpoint-availability questions after the filter was removed.