Four Hundred Thousand Certificates And The Assumption Behind Them
On 23 October, GoDaddy revoked 404,607 SSL certificates because the validation behind them did not meet the policy it claimed to follow. Nobody broke in. There was no exploit, no breach notification, no attacker to name. A large certificate authority looked at its own process, concluded the process had drifted, and pulled four hundred thousand certificates out of the chain of trust.
Three days later, on 26 October, eMudhra announced it was leaving the SSL/TLS market altogether after eight of its CA keys were found to be easily guessable.
Those two items sit in the same week's clipping file as a set of PHP flaws that went from contested proof of concept to active exploitation, an AI coding agent hijacked by a text file in a Downloads folder, an emergency patch batch for a Brotli compression flaw, and a UEFI bootkit that walks past Secure Boot. The temptation is to file the first two under vendor news and spend the column on the vulnerabilities, because vulnerabilities are what security teams are paid to fix.
I think that is backwards. The certificates are the story, and the vulnerabilities are the illustration.
Four hundred thousand certificates is not an incident, it is an audit
Consider what has to be true for an authority to revoke that many certificates at once. It has to know, at scale, that a specific control it asserted in its certification practice statement was not being performed. That means someone went and checked. At most authorities, and at most organisations reading this, that check happens annually, by sample, against a document.
The number is the point. Four hundred thousand revoked certificates is roughly the output of a mid-sized CA for a year or more, which means the drift was not a single error on a single Tuesday. It was a long, quiet, systematic divergence between what the paperwork said and what the staff did. Every organisation runs some version of that divergence. The question is whether anyone is looking for it, and whether they would recognise it if they found it.
Now the eMudhra story, which got a fraction of the attention. Eight CA keys that could be guessed. Not stolen, not extracted through a side channel, not obtained by compromising a hardware module. Guessable. If that description is accurate, then the generation process behind those keys was not a process, it was a habit. And an entity that cannot generate an unguessable key has no business being a certificate authority, which is presumably why it is exiting.
Put the two together and the property they share is this: the trust infrastructure most organisations depend on is operated by third parties whose internal controls are visible to you only through an assertion. You check the padlock. You do not check the certificate practice statement. You could not understand it if you did. The whole design is delegation, and delegation without verification is faith.
The browser will tell you, the appliance will not
Here is the test I would set a team this week, and it takes an afternoon.
Take a certificate that has been revoked. Any revoked certificate will do. Present it to a browser and watch the browser refuse it, because browsers check revocation and have done for years, however imperfectly. Then present the same certificate to the places in your estate where certificates are consumed by things that are not browsers. The pinned CA bundle in a load balancer. The trust store in a VPN concentrator that has not been rebooted since installation. The mutual TLS link between two internal services, written by a team that has since been dispersed. The code signing chain on a build server.
Some of those will reject it. Some will not. The ones that will not are the ones where a revoked or misissued certificate is worth exactly as much as a valid one to an attacker with a network position, and you will not find out which of them fail until you try. Revocation is meant to be continuous. In most estates it is a setting that was configured once, by someone who has left, and never revisited because nothing ever broke.
The commercial question follows immediately. GoDaddy's customers now have to reissue, and reissuance at that volume means deployment windows, change boards and the usual argument about whether the maintenance slot is available. If you bought managed certificates as a service, the contract will say something about the provider's responsibility to reissue. It will say less about who is accountable for the outage when your payment gateway's pinned certificate stops being valid and the appliance carries on trusting it. I have seen organisations discover that their provider's revocation list had never been fetched by half their estate. It is not a comfortable afternoon.
Meanwhile the web stack was being exploited
The PHP2Shell story ran in a straight line. On 23 October, The Record reported that exploitation attempts were growing while researchers publicly questioned whether the available proofs of concept were viable. By 26 October, BleepingComputer reported successful exploitation in the wild. In the middle of that, CISA added a known exploited vulnerability to its catalog. That is the fourth time this year I have watched that sequence run inside a single working week, and the lesson is not that the doubters were wrong about the exploit. It is that doubt is not a window. It is a headline, and headline time is not patch time.
The other half of the same story is unglamorous. PHP does not announce itself. It is inside a Drupal instance a marketing team bought, a Joomla extension nobody has updated since 2023, a Magento installation on hosting nobody in security has credentials for. The vulnerabilities are the visible part. The estate map is the part that decides whether you can close this out.
Then the Brotli flaw. A compression library, embedded in a runtime, triggering emergency patches for .NET, and reported on 26 October as a critical HTTP2Shell vulnerability. Two things are worth noticing here. First, the vulnerability is in a library almost nobody consciously chose and almost everybody ships. Second, the emergency patch cadence means you are now being asked to deploy outside the change process, for the second or third time this month, which is exactly when change control quietly becomes a suggestion.
And the BlackX UEFI bootkit, which exploits the Baton Drop flaw to bypass Secure Boot. Bootkits are the class of malware that makes every control above them conditional, because they run before the things that check anything run. I do not think most organisations can do much about a bootkit in practice beyond measuring Secure Boot state and noticing when it changes. But measuring Secure Boot state is a thing you can do, and almost nobody does.
The agent that reads its own instructions
The item I would put in front of a board is smaller and stranger. On 25 October, BleepingComputer reported that AI coding agents can be hijacked by placing an AGENTS.md file in a user's Downloads folder. No exploit. A text file, in a directory that agents read because reading directories is the job.
The convention that makes these tools useful is that they take instruction from files in the repository. That convention is the attack surface. Anywhere a stranger can write, and everything the agent will read, is now an instruction channel. And unlike a macro or an executable, this one does not trip a scanner, because it looks like documentation.
Layer onto that three items from the same cycle. LiteLLM disclosed on 26 October that an unrevoked key allowed attackers to target its users, which is a reminder that API keys for AI tooling are being minted faster than they are being retired. Dark Reading reported on 23 October that AI tools are generating large attacks at very little cost, which removes the economics that used to keep low-grade criminality low-grade. And BleepingComputer ran a piece on 26 October making the point that when an AI agent is the incident, the agent's identity record is the evidence.
That last one is the practical insight and it is easy to skip past. When something an agent did causes an incident, the question of what the agent was permitted to do, on whose behalf, with which credentials, will be answered from logs and identity records, or it will not be answered at all. Most organisations cannot currently produce that record for a service account, let alone an agent.
What the evidence standard should be
None of the items this week turn on cleverness. The PHP flaw is a bug. The Brotli flaw is a bug. The revoked certificates are a process failure. The eMudhra keys are a generation failure. The agent hijack is a configuration default. The bootkit is a design assumption being tested.
What connects them is that in each case the organisation believed something about its own estate which turned out to be a belief rather than a measurement. The certificates were believed valid because nobody had asked the authority to prove it. The PHP was believed absent because it was not in the asset register. The agents were believed to be tools because nobody had written down what they were allowed to do.
A CISO's job this week is not to triage six stories. It is to close the gap between what is asserted and what is checked, in the three or four places where the gap is widest in their own estate.
What I would do this week
Ask the certificate question first, because it has a deadline attached to it that is not of my making. Pull every certificate issued by GoDaddy in the last twelve months and every certificate issued under an eMudhra root, including the ones embedded in appliances, and test revocation on the non-browser cases before Friday. If you find a trust store that accepts a revoked certificate, that is not a finding for the risk register, it is a change ticket.
Close PHP2Shell first by finding the PHP, not by asking whether you have PHP. Query the hosting providers, the business units, and the agencies running your marketing sites. The known exploited catalog entry is the deadline.
Patch Brotli and .NET on the runtime side, and while the emergency change window is open, take the opportunity to check what other libraries you ship rather than chose.
Write down what your AI agents are permitted to do. Not a policy, an inventory with owners and last-used dates. Revoke keys for the ones that have gone quiet, and block agent reads from user-writable directories. If you cannot tell which agents exist, that is the finding.
And measure Secure Boot state across the estate once, so that next time you have a baseline to compare against rather than an assumption to defend.
None of that is exciting work. It is the work that makes the exciting work survivable.