Leaked CA keys, receipts, and migrations

On October 19, 2026, it came out that eight intermediate¹ signing keys belonging to eMudhra, a certificate authority² (CA, an organization whose signatures make browsers trust a website's certificate), were absurdly weak. Cloudflare's Maxime Guerreiro puts it this way: eMudhra was trusted to pick a 115-digit secret number and picked 4. The other seven secrets were 56, 66, 115, 155, 156, 230 and 237.

That's what sets this incident apart from earlier ones. When DigiNotar, TÜRKTRUST and TrustWave were compromised, only a limited set of attackers or organizations could issue fraudulent certificates. Here anyone can derive the keys and sign a certificate for any domain. Any client that still trusts these intermediates and doesn't enforce Certificate Transparency³ (CT, public logs that every legitimate certificate must appear in) will accept it.

eMudhra has said it is leaving the public CA business. It blames a mistake in a key generation script but hasn't published the script. One odd detail: eMudhra signed a certificate revocation list (CRL⁴, a CA's published list of withdrawn certificates) with what might have been a correctly generated key, then "corrected" it to be signed with the weak key. Cloudflare says that, and the role of eMudhra's auditors and cross-signers (other CAs whose signatures chain eMudhra up to trusted roots), still needs explaining.

Within hours of October 19, Cloudflare patched the most exposed component: the proxies that connect to customers' origin servers. These are built on Pingora⁵, Cloudflare's in-house proxy framework, and they handle most of the company's outbound connections. They now reject the weak eMudhra keys. In parallel, an automated search of the source code listed every other system that trusted these keys within four hours. Each system got a ticket with a preliminary assessment. High-impact systems were patched immediately, and low-impact ones were due by the end of the following week. All high-priority systems are now patched, and a few low-impact tickets are still open.

• About two-thirds were fetches of test sites such as emudhra.we-have-a-problem.com.
• Most of the rest went to origins that seem to have issued themselves a certificate under the weak intermediate.
• About 160 stood out. Their Subject Alternative Names⁶ (SANs, the domains a certificate covers) named other organizations' domains, unrelated to the Server Name Indication⁷ (SNI, the hostname the client asked for). Some of those domains belonged to consumer IoT devices. These certificates were created after the leak, and some were valid for more than two years, which is longer than any public CA may issue.

• Oct 23, 15:30: the control was switched to an eMudhra certificate without (the CT log receipts). Acceptance differed somewhat, but not much.

Up-to-date mainstream browsers are mostly patched. Bots and old browsers mostly aren't. Embedded browsers such as Android WebView¹⁰ lag, with 30–40% still accepting the weak chain. Probes showed clear patching over the first weekend, during the monitoring gap, and little movement since.

Broken down by network (ASN¹¹, autonomous system number, which identifies an ISP or other large network), more than half of probes from large networks still accept the compromised chain, with or without bot signals, and the trend has been flat since the weekend. Guerreiro argues that bots are still software that needs updates. If they reflect how software gets updated in general, "the picture is quite dire."

The advice is to patch. Dennis Jackson runs a crowdsourced site with per-platform instructions, and Cloudflare singles out macOS developers. Cloudflare customers using WARP or Tunnel should follow the company's earlier post. Longer term, Cloudflare argues trust stores can't stay static root lists. It already uses quick revocation in some products and backs projects like upki¹², which push revocation data and CT log keys to clients quickly.

Will Larson, who leads engineering at the fintech company Imprint, describes the next step in how his team develops software. They call it a verification loop. Every pull request must now carry a written record of how its changes were checked. A daily job then mines those records to improve the tooling. A caveat up front: the "harness¹" doing most of this work is an AI coding agent. The article is mostly about steering agents, which sits at the edge of this digest's scope. The quality-loop design is the part worth reading.

Larson says the name causes confusion. When teams hear "verification pattern" they ask what new mechanism will check the code, since tests and linters already exist. The answer is that it adds none. He compares it to chain-of-thought² prompting, where you make the system spell out its reasoning step by step so you can steer it toward the result you want. Here the steering is a required document. Each pull request must produce a file at verifications/{pr_num}.md. It lists every step taken to verify the change, and also what the agent was unable to verify.

Why require a document when the agent might already run these checks? Larson's point is that you can't tell whether it did. His evidence is mundane: too many pull requests reached CI/CD³ (continuous integration and deployment, the automated build-and-test pipeline) still failing basic lints that could have run locally. Requiring the agent to say "I ran the linter" or "I couldn't" turns a hidden process into a visible one.

The loop can't see failures that happen before a verification file gets written. If the container running the job crashes partway through, no file appears, and nothing is there to mine. To cover this, Imprint uses a separate "feedback tool⁵", following Teddy Riker's essay Designing for Agents. Through it the system reports problems with CI and its own environment, above the level of any single pull request. Larson calls the two techniques complementary: verification files catch gaps in checking a specific change, and the feedback tool catches broken infrastructure.

His stance is firm on one point. He calls conflicting guidance "context poison⁶" and is pushing to remove duplicate guidance on any topic, so there's one consistent source per area. Imprint runs the loop centrally, building a single continually improving body of guidance for each code area. He acknowledges internal skepticism about how far the centralizing should go and calls it warranted: he expects the best techniques a year from now to be mostly unknown today, so some exploration has to continue.

Stripe pays nearly 20,000 vendor invoices a year in more than 70 markets. By October 2026 it had moved most of its US and UK vendor payments onto Global Payouts¹, a product it sells for sending money to people who don't have Stripe accounts. Over $1 billion has gone to more than 3,400 vendors this way. This is a vendor post about Stripe's own product, so read it as a customer case study written by the seller. Still, three of its lessons apply to any payments system, and it describes how the migration was run.

Stripe used to pay vendors through direct integrations between its ERP² (enterprise resource planning system, where invoices and accounts payable live) and individual banks. Where no integration existed, staff typed payments into bank web portals by hand. Every bank relationship had its own technical, contractual and security requirements, and building one for a new market took up to six weeks. When a payment failed, operations and finance staff had to search several bank portals and the ERP to find out what went wrong before they could resend it.

Global Payouts puts one API in front of that. Through it a business can pay recipients in more than 160 countries by local bank transfer, international wire, or stablecoin³ (a cryptocurrency pegged to a fiat currency such as the dollar). In Stripe's own setup, an internal orchestration layer⁴ turns ERP vendor and bank-account records into the API's "recipient" and "payout method" objects.

• February 2026: canary payments. Stripe sent one low-dollar ACH⁵ or wire payment through each US payment flow. ACH is the US batch bank-transfer network. Each distinct path was proven with little money at risk.
• March 2026: four waves. Payment amounts went up only once nearly all eligible payouts in the previous wave had succeeded. The gate was based on how much money was at stake, not just how many payments ran, which is relevant to Lesson 3.
• By June 2026: Global Payouts carried the vast majority of Stripe's domestic US vendor payments, by both count and value.

Stripe added customisable statement descriptors⁶, the short text that appears on the recipient's bank statement, so senders can include something recognisable such as an invoice number. The lesson is that your observability isn't enough if the other side of the transaction has to reconcile from what the bank shows them.

Global Payouts was built for tens of thousands of payments. Some of Stripe's vendor payments were larger than the system's per-payment limits, and those fell back to manual handling, outside the automated flow. Stripe raised ACH and wire limits on its Outbound Payments API⁷ to $100 million per payment. Those large payments now go through the same approval, ERP recording, funding, reconciliation and reporting steps as everything else, without a side channel.