Anthropic's Deputy CISO Says Hold On for Eighteen Months. We Measured the Same Gap Three Times This Week, and One of the Measurements Was Our Own Laptop.
On October 22, Jason Clinton, Anthropic's Deputy Chief Information Security Officer, posted that "as bad as things have gotten in the past 4 days, they are going to get a lot worse before they get better." Asked by a critic whether this was always where it was heading, he replied: "yes. it was always going to be this way. we tried to warn the world." His guidance was four words long. "We need to hold on for ~18 months."
He has described what is coming as a vulnerability tsunami: frontier models getting better at finding and weaponizing flaws than defenders can patch them. The destination he points to at the far end of the eighteen months he calls vulnzero — a state where advanced reasoning has shrunk into cheap models that check every line of code in real time and stop whole classes of bugs before they ship.
We think he is right, and we spent this week measuring the thing he is describing. We got three measurements. They do not say quite what you would expect.
The gap is not where most people think it is
The intuitive version of the tsunami argument is that patches will not arrive fast enough. That is coming. But it is not what broke this week.
In all three of our measurements, the patch already existed. What failed was whether it took effect.
Measurement one. Collabora's built-in office server for Nextcloud, CVE-2026-110447. The fix was committed on September 9 and shipped on September 11. The first attack in an administrator's log was September 10. CISA added it to the Known Exploited Vulnerabilities catalog on October 23. That is forty-two days in which a patch existed, the flaw was being used against schools and nonprofits, and it was absent from the list most people sort their queue by.
Measurement two. Baton Drop, CVE-2022-21894. Patched in January 2022. Used by the BlackLotus bootkit in 2023 and again last week by BlackX. It still works because the patch was not a code change: it was a decision to stop trusting a certificate, and applying that decision is a separate manual step in firmware. Four years on, the CVE is still not in the KEV catalog, and the honest reason is that the remediation can stop a fleet from booting if done in the wrong order, which is hard to write as a three-day federal mandate.
Measurement three, and this is the one that cost us something. Last Friday a researcher recovered eight of a certificate authority's private keys, which turned out to be integers under 256. Browsers blocked them within hours. Apple blocked on October 22. On October 23 we tested our own machine and published that the system curl and system Python on our operator laptop still trusted the forged chains, and we said we would retest after the pending operating-system update.
We applied it. That laptop is now on macOS 27.0.1, a full major version past the update we were waiting on. System curl still returns a clean 200 on all four test chains. The chain it accepts is issued by one of the eight weak intermediates, and curl's own verdict on it is "SSL certificate verify ok." System Python still completes the handshake. Node.js on the same machine, carrying its own root store, refuses all four as revoked.
Seven days after the vendor block, across a major operating-system upgrade, on a fully patched machine.
What that adds up to
Patch state is not trust state, and nothing in a patch report measures the difference. There is no field anywhere that tells you whether a shipped fix is actually in force on the thing in front of you. We looked for ours and found it absent twice on our own hardware, by hand, in about two minutes each time.
If the tsunami argument is right — and we think it is — then this is the part that gets drowned first. Not "we could not get the patch." We had the patch. We had it for forty-two days, or four years, or we had the whole operating system replaced underneath it. The attacker does not care which.
The eighteen months, and the part that does not need to wait
Clinton's near-term advice is unglamorous and correct: air-gaps and data diodes now rather than waiting on fixes, and using board attention to fund patch management, access control and network segmentation. He also warns CISOs not to rush into half-finished AI security products. We are going to take that caveat seriously, including about ourselves, because it is the right instinct and because we would rather be checkable than impressive.
So here is the narrow thing we would say, held to that standard.
The vulnzero destination is cheap models checking code before it ships. For one specific layer — the dependency you are about to install — that check does not need a frontier model and does not need eighteen months. It needs a deny-list, a reputation record, and a version-scoped vulnerability lookup. We built that. It answers allow, review or block with the record behind the answer, it costs about four tenths of a cent per check, and it runs no language model at all. It is free, read-only, needs no account, and works inside Claude through the connectors directory.
That is not the tsunami solved. It is one layer of one problem, available today, at a price that rounds to nothing.
The unit economics run the other way
Anthropic's September threat report contains the line that frames the money: "the adoption of AI threatens to quickly and easily subvert defenders' ability to impose costs on adversaries." That is the correct worry in general. On this particular layer it is worth checking the arithmetic, because the arithmetic does not agree.
A dependency check costs about four tenths of a cent and runs no model. Our entire language-model bill for thirty days of research, including the model calls behind two hundred and fifty domain audits, was thirty-one dollars. The two-minute test that caught our own laptop trusting a revoked certificate cost nothing but attention.
Now price the other side. An attacker running an agent framework through a cloud environment pays per token, per hour, per proxy, per burned domain — and every one of those costs scales with the number of targets. A deny-list lookup does not. It is the same four tenths of a cent whether one person runs it or a hundred thousand do, and the answer gets better as more people contribute to the list.
That is the whole thesis, and it is not complicated: on the pre-install layer, defense is simply cheaper than offense, and it is cheaper per unit the more it is used. Attack cost scales with targets. Check cost does not. Any defense whose price does not rise with adoption is one you should be using before the expensive kind, and most of them are already free.
We think this is the part the tsunami framing is missing. Not every layer of this problem needs a frontier model and eighteen months. Some of it needs a list, a lookup, and somebody to actually run it.
Our own denominators, since we are asking you to trust a measurement
Fair is fair. If we are going to publish numbers about other people's patch gaps, here are ours.
Sixty-six package checks ran in the last thirty days. That is a small number and it is the number we are trying to move. We have published twenty-three corrections against our own posts this year, dated, with the original claim left visible beside the retraction — including one yesterday where we claimed a two-month detection lead and our own timestamps showed we were a day late. Today we corrected ourselves twice more in private before publishing anything: we told a researcher a CVE did not exist when it did, and we called a KEV nomination strong when it does not meet CISA's bar for active exploitation.
We cap every confidence claim at ninety-five percent on principle, because something here is wrong and we would rather say so than find out from you.
What we cannot do: we have no visibility into firmware implants, we hold no indicators for BlackX, and our edge instruments saw nothing of the PHP exploitation wave that filled everyone's honeypots this week. We said all of that in the posts where it mattered, because a sensor that could not have fired is a gap and not a result.
The part nobody is saying out loud
Anthropic's own September threat report contains the sentence that reframes this: "AI has collapsed the labor and tooling gap."
Everyone is reading that as an attacker story. It is also a defender story, and we are a small piece of evidence for it. This week, two people published two researched posts with verified diagrams, measured three patch-effect gaps, retested a claim on our own hardware and found our previous week's conclusion unchanged in the wrong direction, maintained a two-million-record indicator feed, and ran a pre-install gate that refused its own operator three times and was right every time.
That is not a boast about headcount. It is the point. If the collapsed labor gap is why a lone operator can now run dozens of intrusions in parallel, it is also why a two-person shop can measure what a vendor would have needed a team to measure. The asymmetry everyone is afraid of runs both directions, and almost nobody is building on the defensive side of it.
Eighteen months is a long time to hold on. Some of the holding can be done with a two-minute test and a free check, and you do not have to wait for a frontier model to shrink before you run either one.
If you test one client against a revoked chain because of this, or if we have the mechanism wrong, the rating widget below takes ten seconds and is the only way we know.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=anthropic-s-deputy-ciso-says-hold-on-for-eighteen-months-we-measured-the-same-gap-three-times-this
Comments