In partnership with

Last week was a lot. I can't remember seeing this many vulnerabilities and incidents in such a short stretch, and picking one to cover took longer than I expected.

Life needs to be interesting, I guess. I had something a little more fun in mind. 🤷

TL;DR: A certificate authority (CA) signs certificates that let software verify the identity of an HTTPS service. Eight eMudhra CA private keys were so weak that researchers could recover them from public certificates. We'll follow the impersonation risk into the separate trust stores inside our containers and agent sandboxes, then check the fix there.

A browser update tells us little about the CA bundle, the list of trusted authorities, inside a build image. Our package downloads and cloud API calls can use that separate copy.

Attack of the week: signing a certificate with a guessable key

Scott Helme reported on October 20 that one of the private keys was the number 4.

An intermediate CA uses its private key to sign certificates. Clients check those signatures with public keys and follow the certificate chain to a root they trust.

These 8 private keys were numbers between 1 and 255. Helme tried candidates and matched their calculated public keys to the certificates, recovering all 8 in under a second.

An attacker can use a recovered TLS-signing key to create a certificate for a chosen hostname. If they can intercept or redirect our connection, they can present that certificate from their own server.

The client checks the certificate's name and signature chain. If it still accepts the compromised authority, the forged certificate can pass.

Helme demonstrated this locally with curl, Python and Node. His test impersonated a service on his own machine; it wasn't evidence of a breach at that service.

Recover a weak CA key, sign a certificate for a chosen hostname, intercept the connection, then present it to a client that still trusts the chain.

Impersonation requires both a network position and a client that accepts the affected certificate chain.

The incident report published by Dennis Jackson, dated October 20, says the keys were recoverable from certificates created in April 2025. Historical exploitation against nonbrowser clients is unknown.

It also explains the browser distinction. Clients that enforce Certificate Transparency (CT) require public-log evidence before accepting a certificate. The incident team reports no relevant entries during the exposure period and cites that absence as evidence against past attacks on those clients.

Browser updates also block the affected intermediates. Many other clients need software or trust-store updates to reject the compromised chains.

Ship this week. Pick a build runner or agent sandbox that downloads dependencies. Identify the client doing the download and the CA bundle it uses. Check the running environment.

Defender's corner: update the sandbox's copy

Docker's guidance, updated October 21, says its built-in sandbox templates have been rebuilt. Updating the sbx command-line tool or pulling a new image leaves existing sandboxes unchanged.

For an existing Ubuntu-based Docker sandbox that's running, run these commands on the host. Replace SANDBOX with its name:

sbx exec SANDBOX -- sudo apt-get update
sbx exec SANDBOX -- sudo apt-get install --only-upgrade -y ca-certificates

Restart applications afterward. Clients that bundle their own CA certificates need their own updates.

For new sandboxes, add --pull always to sbx create with the required arguments. Save work before recreating one. Removing a sandbox deletes its filesystem, including unpushed commits.

Custom templates need the distribution's trust-store update and an image rebuild.

Test certificate rejection through the workload's actual client after updating an existing sandbox's CA bundle or creating a sandbox from an updated template.

A fresh image on disk leaves an existing sandbox's trust store untouched.

For cloud workloads: Google's October 23 GKE bulletin says application containers don't inherit the node's root CA store. Follow the bulletin's cluster and node guidance, and separately rebuild and redeploy application containers with patched base images.

For AWS Python SDK clients, AWS's October 24 bulletin calls for botocore version 1.43.117 or later. Check the installed version inside the runner or container that makes the request.

Verify the result. The incident site provides test hosts for both affected trust paths. Run these from inside the environment being checked:

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

Expect rejection because the certificate chain is untrusted. Save the error: a timeout, DNS failure or unrelated certificate error is inconclusive.

If a TLS inspection proxy replaces the certificate, this request won't test the workload's trust in the original chain. Check that the proxy rejects the compromised certificate chain. Use the incident site's downloadable certificate chains to check whether your application also rejects them with its usual certificate validation and trust settings.

These URLs test one affected intermediate through 2 root paths. The incident site provides a fuller set; repeat validation through the client our workload uses.

The checker's “No CT” tests use certificates absent from transparency logs. Acceptance shows continued trust without CT enforcement; rejection alone doesn't prove the CA was removed.

Do this week: record the client and CA-bundle versions with the verification result. Record a new image digest when rebuilding; an in-place package update leaves the original digest unchanged.

R.K.

Full archive: join.defensive.works

Nobody's coming to approve your idea

People assume that real businesses get built by other people with more resources. It's how great ideas get stuck in notes apps and conversations.

But you don't need six months and a developer's salary to validate your concept. You just need a weekend. Describe what you want to exist and Lovable builds it: a real site, a real product, ready to accept real payments from real customers. Not a mockup to show people. An actual thing they can use.

You don't need anyone's sign-off to get started. Take $5 off your first month.

Discount of $5 applies to first month of any paid plan. You need to sign up via this webpage in order to claim the discount. The discount applies to new and returning users without an active paid plan. Terms apply.