Why the patch gap on your website matters more now
The patch gap is the time between a security fix being published and that fix running where it's needed. Between 17 August and 7 September 2026, I checked public install data for Statamic and found that 26% of installs were still missing a security fix that had been out for over a month.
Those figures come from Packagist, the directory the PHP packages behind a Statamic site are installed from. It counts installs rather than websites, so treat the number as a rough guide. It still shows how a security gap can stay open.
What is the patch gap?
Mozilla, the organisation behind the Firefox browser, wrote about it on 29 October 2026 in Defending the patch gap against automated attackers. It defines the patch gap as "the window in time between the appearance of a security fix in the code and the full deployment of that code to most users."
The window in time between the appearance of a security fix in the code and the full deployment of that code to most users
A fix is a set of changes to the code, and those changes point straight at the vulnerability. Anyone can compare the old code with the new and work backwards to it. Then they can attack every copy that hasn't been updated yet. This used to take real skill and time, so few attackers bothered.
Why artificial intelligence makes the gap more dangerous
Mozilla says artificial intelligence (AI) models "can now identify software vulnerabilities as effectively as top security researchers". That's good news overall. Firefox has shipped more than seven times as many security fixes since February 2026 as it did in the same months of 2025.
The same tools make working backwards from a fix cheaper. Mozilla has seen evidence that GLM 5.3, a model anyone can download, can exploit some fixes for vulnerabilities found by more advanced models. Its response was to halve its release cycle so updates reach users every week. It also keeps the tests that show each bug private until the fix has shipped.
For how quickly attackers moved on a real vulnerability, see what PHP2Shell tells us about AI cyber attacks.
On a Statamic website, the patch gap belongs to you
Firefox updates itself, so Mozilla can shrink the gap by shipping faster. A website doesn't work that way.
Statamic, Laravel (the framework it's built on) and PHP (the programming language behind both) are all open source. Their fixes are published in public on GitHub, so the clock starts the moment a fix appears. Nothing changes on your site until someone runs composer update, checks that nothing has broken and deploys it. Composer is the tool that installs those packages.
Mozilla also says keeping code secret is "at best a speed bump", because modern tools can rebuild source code from the finished program. Open source isn't the problem. Out-of-date software is.
On your website, the people who make Statamic start the clock. Whoever looks after your site decides when it stops.
Doesn't a dependency cooldown make the gap wider?
Yes, on purpose. I use a dependency cooldown to stop new package releases installing until they're two days old. It guards against a different risk: an attacker publishing a poisoned version of a package you already trust.
The two fit together once someone decides which release is which. Routine releases wait out the cooldown. Security releases get checked and installed straight away. Running composer audit before every update lists any installed package with a known vulnerability, so the urgent ones stand out.
How short should the patch gap be?
The UK government's Cyber Essentials scheme allows 14 days for critical and high-risk security fixes. Mozilla has moved Firefox to weekly releases. With AI making fixes quicker to reverse, I treat 14 days as the outer limit, not the target.
On my website maintenance plans, critical and high-severity fixes for Statamic and the packages a site uses don't wait for the monthly update. I typically apply them within one business day. Server security updates install automatically every day.
Being in the gap isn't the same as being hacked. Most sites that run behind for a while never get attacked. Keeping the gap short means you're not relying on that luck.
If you don't know how long your site's gap is, ask whoever looks after it when the last Statamic security release went on, and how long it took after it was published.
You might also like...
- Plan your Statamic 5 upgrade while it's still supported
- Your Statamic 3 site still works, but it can't be kept secure
- Still on Statamic 4? Updating PHP isn't enough
- PHP2Shell is patched on every site I maintain
- Critical PHP Security Update Incoming
- Statamic Sentinel 3.0
- Statamic 5 security countdown: fixes stop in December 2026
- Darkroom: a Statamic AI image generator for Nano Banana
- Tracer 2.0: my Statamic UTM builder gets site-wide settings
- Statamic 6 security depends on keeping up with releases