The Take — Stop blaming open weights for the patch gap

Six consecutive Firefox releases fell to a downloadable model at roughly $1,000 a version, and the reflex will be to reopen the open-weights liability argument. That reflex is wrong. The vulnerability that made this work was not the model — it was a release calendar that hands attackers a machine-readable map of every flaw before it hands users a fix.
The experiment is Epoch AI's, and it is clean enough that the argument can be had on evidence rather than vibes. GLM 5.3, Z.ai's open-weight model from August, was given a target Firefox build and nothing else: no vulnerability reports, no insider information, no human directing the search after the initial brief. It compromised every version shipped between September 17 and October 26 — six releases — by reading fixes that had been published but not yet installed everywhere. Each success chained a bug derived from a public patch diff to a second, undisclosed sandbox bypass that the model rediscovered on its own. The end state was a webpage that read a file off a visitor's machine and sent it to an attacker's server with no user interaction — not full code execution on recent builds, but saved passwords, session cookies and documents are the whole reason people use a browser.
The numbers are the part worth arguing about, and the ones that get quoted are the wrong ones. Epoch's report puts marginal cost at about $1,000 per version at API pricing, and lower on consumer subscription accounts. That four-figure figure is not the story. The story is that the fixed cost was about $100,000 of research and compute spent building the harness once, after which every additional target was a credit-card transaction and a waiting period — twelve hours at the fastest, against a 48-hour ceiling the researchers allowed themselves.
The cost that actually matters is not the model's
A $1,000 marginal exploit price sounds like a capability story. It is a scheduling story. Twenty years of coordinated disclosure assumed that reading a patch diff and turning it into a memory-corruption primitive was a scarce skill — scarce enough that the handful of people with it were reputationally bound, and scarce enough that a vendor publishing a fix was usually publishing it to defenders first. Firefox's team still behaves as if that assumption holds: as our morning brief noted, Mozilla disguises security work as routine maintenance precisely to blunt this attack, and GLM 5.3 sorted the security-relevant changes from the cosmetic ones anyway.
So the scarce input moved. It is no longer expertise; it is the window between a diff becoming public and a patch becoming universal. Right now that window is structural: Firefox and Chrome both update weekly, which means a fix published on day one gives an attacker six days of guaranteed coverage over the population that has not restarted. Epoch is careful to separate the two halves of the gap — the fix-before-release half, and the users-still-running-old-software half — and the industry has spent its effort on the first while treating the second as the customer's problem. That is a choice, and it is one the open-weight cyber argument has been circling since August without naming.
Why liability aimed at the weights misses
The policy conversation that follows a report like this will be about Z.ai, or about whoever releases the next capable open model. It is a category error, for two reasons.
First, the model is the cheapest component in the attack chain. Epoch spent more on the harness than it would spend attacking a hundred browsers afterwards, and the harness is now a template. Second, refusal behaviour is not a lever at the weights: we covered in September that stripping GLM-5.3's guardrails cost about $4,400, and the resulting model runs on rented hardware with no endpoint to log a request. A liability regime that governs how a lab releases weights, on the theory that a hosted API would have refused, is regulating a door the attack does not use.
The point of control is the calendar, and the vendor holds it: not when a bug is found, but when the fix becomes readable and how hard the update is pushed. That is not a new kind of obligation. Vendors already embargo vulnerabilities for ninety days and nobody calls it obscurity. Shipping a fix without shipping it to ninety-plus percent of users is the thing being priced at $1,000 a unit, and the bill lands on people who never agreed to run a browser with a known, published hole in it.
The counter-case, and it is strong
The best argument against me is that opacity is where security goes to die. Fixes held in private trees rot; backports diverge from trunk; independent researchers cannot verify that a patch closes the bug rather than moving it; and the entire disclosure ecosystem — advisories, CVE identifiers, distribution security trackers — assumes the details eventually become public and checkable. There is also a decent empirical case that the alternative already failed: vendors patched silently for years, and the practice died because it protected vendors' reputations, not users.
The counter-case gets stronger when you push on mechanism. Hiding a source diff does not hide the fix; the fix is in the binary. Binary diffing is older than coordinated disclosure, and an attacker with the shipped build can recover much of the same signal a source diff provides — slower, but not impossible. If that is true, a policy of delaying diff publication buys days rather than immunity, and the honest fix is update velocity.
And there is the brittleness Epoch itself flags. The same harness and roughly $100,000 of API spend against Chrome produced no equivalent exploit. The capability does not transfer automatically; it targets the cheapest browsers first, which is how real attacker economics have always worked. Anyone legislating off six Firefox versions is legislating off a demonstration, not a trend.
Why the take still holds
Because the demonstration is the trend, and the trend just got a price. Kimi K3.1 Pro ships weights in early November and its own benchmarks suggest it beats GLM 5.3 on offensive cyber work. Anthropic has already shown a frontier model exploiting the Windows patch gap with no source access at all, which is the closed-source version of the same failure. Every one of those developments pushes the marginal cost of a working exploit down and the required skill floor toward zero. A regime built on the assumption that diff-reading is elite work is going to keep producing four-figure exploits and six-day exposure windows, and then seven-figure breach costs that the people exposed to them never priced.
What I want instead is narrower and cheaper than a liability bill. Vendors should stop chaining chainable fixes into a single release, so one public diff does not advertise two bugs. They should be able to hold the content of a security diff — not the existence of it — until forced-update coverage clears some threshold, and then publish it, which is an embargo extension rather than a transparency rollback. And they should measure the number that currently goes unmeasured: median hours between a fix becoming public and eighty percent of users running it. That number is a release-engineering metric, and unlike "model safety," it is one you can actually move.
What would change my mind
Show me that binary diffing recovers what source diffing gives, at comparable speed and cost, and the diff-delay argument collapses into theater — I would then argue only for update velocity and against everything else in this piece. Show me a vendor that ships daily and still loses versions to patch-gap attacks at $1,000 a head, and the calendar theory is wrong too. And if a study finds that withheld diffs measurably delay defenders — third-party auditors, downstream maintainers, distributions shipping backports — more than they delay attackers, I will take the transparency side and accept the exposure window as the price of a checkable fix. Until one of those lands, the $1,000 is a bill for a decision nobody is being asked to defend.
Is a four-figure browser exploit a vendor release-process problem or a model-release problem? Write to us via our contact page.







