Six hours early
At 07:41 UTC on Oct. 21, Chainguard, a software supply-chain security company, published PHP container images that carried fixes for two remote-code-execution flaws. Under the coordinated disclosure plan PHP had agreed with distributors, those fixes weren't due to go public until 14:00 UTC. In a post-mortem that day, the PHP Foundation wrote that Chainguard "unilaterally broke the embargo," and that "any attacker could now study the fix in binary form while every other PHP user was still waiting for the release."
Eight days later a similar problem surfaced in Firefox, this time with an open-weight model reading the patches. On Oct. 29, the research group Epoch AI published a report showing that GLM 5.3, a model Z.ai released in August, read Firefox security fixes that were public but not yet shipped, and used them to build attack pages against all six Firefox releases that came out between Sept. 17 and Oct. 26. A user who opened the page would have a local file read and sent to the attacker. Mozilla answered the same day with changes to how it ships Firefox.
The two episodes look unrelated, one a vendor fight over who broke an embargo, the other a study of how dangerous open-weight models have become. Taken together they describe one shift. AI has made bugs cheap to find, open-source projects are fixing far more of them, and every public fix tells outsiders where a hole was. Security people call the stretch between a fix appearing and that fix reaching users the patch gap. For open-source projects, that gap is where the security bottleneck now sits, more than in finding the bugs.
Mozilla and Epoch both list ways to shrink it: ship faster, keep fixes private until release, stagger when different kinds of fixes become visible. Each of those takes money, staff, an architecture with layered sandboxes, and some of the openness open-source projects are used to. Mozilla itself says that much of the software on the internet "has not had the luxury of these preparations."
How much a patch gives away
Epoch set the bar low on purpose, aiming to emulate "a relatively unsophisticated actor with limited resources." Researchers gave GLM 5.3 the target Firefox version, some basic tools and the public information available when that version shipped, told it to look at bug fixes not yet in the stable release, then let it run offline with no further input. The model picked out which code changes were security fixes, chose vulnerabilities and assembled the exploit chain itself. Firefox's security fixes are disguised as ordinary improvements, Epoch noted, but GLM 5.3 "was able to read the code and determine which changes related to security patches."
The report is specific about cost. Epoch spent more than $100,000 in API fees on the Firefox work, much of it building a realistic offline environment and early testing. Once that was in place, the marginal cost of compromising another Firefox version was about $1,000. Each attempt had up to 48 hours; the fastest took 12. No provider, including Z.ai's own API, refused or flagged the requests.
Mozilla's response, signed by Bobby Holley, connects this to the frontier labs. "We've seen evidence that models like GLM 5.3 can exploit some of the fixes for bugs originally uncovered by more advanced models," it says.
That sentence describes a transfer. As Epoch puts it, frontier labs have given some defenders early access to their strongest bug-hunting capabilities while heavily restricting wider use. Mozilla says the Firefox team has used frontier models from Anthropic and OpenAI since February and has shipped more than seven times as many security fixes as in the same period of 2025. The security advisory for Firefox 159, released Oct. 27, lists 167 CVEs, 108 of them rated high. Forty-one are credited to OpenAI, 34 of those to "OpenAI Codex Security (kylebot)." One caveat: with this advisory Mozilla stopped rolling internally found memory-safety bugs into a single CVE and now issues one per bug, so 167 can't be compared directly with older releases.
The more the frontier models find, the more fixes land, and once a fix is in a public repository it becomes a clue that a model several generations behind can follow. Part of the head start defenders get from restricted access leaks out when the patch goes public.
PHP: even the rumor is a clue
PHP's case goes a step further. According to the foundation, the two CVE IDs began circulating on forums and social media at around 15:00 UTC on Oct. 20 with a wrong release time and a wrong 10.0 severity score, and "no technical details leaked." PHP moved its release up a day. Calif, one of the firms that found the bugs, then mistakenly posted a video of its proof of concept, and mitigation advice PHP had sent a few critical-infrastructure providers may also have leaked.
Telemetry from Fastly, the content-delivery company, fills in the timeline. The first tool named after "PHP2Shell" appeared at 03:59 UTC on Oct. 21, and the most widespread exploit kit at 05:11, both before Chainguard's 07:41 images. By the 14:00 release, more than 100 source IPs had used such tools. "We won't speculate what prompted any particular tool," Fastly wrote.
Chainguard Chief Executive Dan Lorenc didn't dispute the timeline but told The Register his company "didn't leak." He said Chainguard heard on Oct. 16 from a researcher that "something was coming in PHP," and that night found the same bugs on its own with its AI harness and a frontier model. "Just being told there's a vulnerability in a piece of software - even something as big as PHP - is enough to find it," he said. He shipped early, he said, because other vendors reported exploitation in the wild: "It's coordinated vulnerability disclosure, unless there's evidence of active exploits in the wild." The PHP Foundation says its security team "did not identify any functional exploits at the time of release/public disclosure."
The two sides disagree about this one release. But if Lorenc is right, an embargo protects less than it used to. The patch is a clue, the CVE number is a clue, and so is the bare news that PHP has a serious bug.
Why fixes are slow
The PHP Foundation's post also contains an unusually frank admission. The out-of-memory problem behind CVE-2026-109618 first showed up in 2024, when a foundation-contracted core developer spotted signs of it while fixing an issue from an outside audit. The security team came up with several fixes, each with a cost: broken backward compatibility, new denial-of-service risk, or changes to many third-party extensions. Working by consensus, with few people who know the engine deeply, the effort stalled and restarted "repeatedly over months." The foundation wrote: "We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources."
AI has also raised the volume. Since July 1, the foundation says, the security team has published 15 CVEs and worked through more than 100 reports that were invalid, duplicates or not reproducible. Tools can find bugs faster, it wrote, but they cannot "decide on the right fix for a long-standing design decision in the engine, weigh the compatibility trade-offs, and review the patch."
That lines up with Firefox. Finding bugs keeps getting cheaper. Fixing them, reviewing the patches and coordinating releases doesn't, and every day of delay gives public or half-public clues another day to be used.
Mozilla's fixes, and their price
Mozilla lists three steps already taken. Earlier this year it halved its release cycle, so new builds now reach users every week. It went back to keeping regression tests confidential until a fix ships, because it saw that GLM 5.3 "is much less effective at patch-gapping when a regression test is not present." And it scans every new commit that lands in the Firefox codebase.
The new measure leans on architecture. Firefox has several layers of sandboxing, so an attacker generally needs at least a renderer exploit chained with a sandbox escape. Mozilla plans to group classes of fixes so that their patch gaps don't overlap: at any moment, only one ingredient of a full compromise would sit in the gap, and the attacker would have to find the other from scratch. Getting this right, Mozilla said, "may take some time."
Each step has a price. Confidential tests mean outside contributors can't see the full reasoning behind a change until it ships. GitHub's temporary private forks let open-source maintainers fix a flaw out of public view, but its documentation says that to keep the work secret, integrations including CI can't access the fork and status checks don't run. Weekly releases need reliable automated testing and a release team. Staggering the gaps only works if the code is layered so that one bug alone isn't enough.
"Unfortunately, much of the software that powers the internet has not had the luxury of these preparations, and is now more deeply exposed," Mozilla wrote. In a footnote it added that hiding source code is "at best a speed bump," since tools can increasingly reconstruct source from binaries. "Firefox is proudly open-source and we have no intent to change this."
What not to overstate
Epoch's result has clear limits. None of the six successes relied on the patch gap alone. Each also used a then-unpublished sandbox flaw that GLM 5.3 rediscovered on every attempt. Mozilla fixed it in Firefox 159 on Oct. 27; Epoch says it hasn't confirmed whether the attack still works there but expects it to be "substantially more difficult." The exploit read local files; Epoch says it has no code-execution successes on recent Firefox releases. Pointed at Chrome with the same harness, Epoch spent about $100,000 more without success, though it says that doesn't rule out success with better elicitation or a more capable open-weight model.
This was a controlled experiment. Neither Epoch nor Mozilla reports anyone using an open-weight model this way against Firefox users. Mozilla also says the depth of bugs such models can find in Firefox "has largely been picked clean." And Epoch notes that open-weight models also help defenders who lack access to frontier models, and says its report makes no claim about the overall offense-defense balance.
What it means for small teams
For small teams maintaining open-source AI tools, inference frameworks or plugins, the signal is specific: a fix merged is not a user protected. In Epoch's experiment, the stretch between the two had a price, about $1,000 a version once the setup was built.
Some of Epoch's suggestions scale down: keep a fix private until it's ready to ship, move from beta to release quickly, and avoid patching several chainable flaws at once. Mozilla's playbook shows the ceiling. Weekly releases, confidential tests, commit scanning and fixes staggered by sandbox layer sit on top of an engineering team that now fixes security bugs at more than seven times its old rate.
The PHP Foundation's answer is blunter. It ends its post by asking companies, hosting providers and distributors that depend on PHP to fund more engineers who know the PHP engine well enough to fix it and review the patches. The models that find bugs are priced per API call. The people who review patches and ship releases aren't, yet.