php2shell and Statamic: the fix you can't composer require

On October 21, 2026, PHP released 8.2.35, 8.3.36, 8.4.27, and 8.5.12 to close two critical engine bugs, CVE-2026-109618 and CVE-2026-109619, now known together as php2shell. With the right request, an attacker can run code on an unpatched server without an account. If any of your Statamic sites runs on a server whose PHP you haven't updated since then, do that before anything else.

For once, there is nothing to composer update. Statamic, Laravel, and your addons play no part in the fix. They only decide which PHP versions you can run, and therefore whether a fixed release exists for you.

What to do now

1. Check the PHP version on every server that runs a Statamic site, including staging and build machines.

2. Update to PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer, or your distribution's patched package.

3. Restart PHP-FPM, queue workers, Horizon, and Octane, so nothing keeps running the old engine.

4. Put every Statamic 5 site on the upgrade list. Statamic 5 and PHP 8.2 both lose security support on December 31, 2026.

What the bugs do

The short version: one crafted request, no account needed, and on Apache with mod_php the attacker's code runs before your application has even started. Both CVEs carry a CVSS 4.0 score of 9.2. Under the hood they are memory safety problems. CVE-2026-109618 hits when a request exhausts its memory limit mid-setup and PHP's cleanup then trusts data that was never fully built. CVE-2026-109619 lets internal state from one request outlive its memory, so the next request on the same worker can stumble into it.

Laravel was tested directly. The security firm Calif, which reported the bug, confirmed unauthenticated code execution against Laravel 13.11, which is one of the two Laravel versions Statamic 6 supports. Because the problem lives below the framework, nothing in your app gets a say: not middleware, not CSRF protection, not Statamic's two-factor login or elevated sessions. Setting session.upload_progress.enabled=0 in php.ini closes one known attack path, but the PHP team is clear that only the update fixes it.

Why the bug sat unfixed for two years, and how the disclosure fell apart two days before release, is a story of its own. I wrote it up in detail for CraftEntries.

The Laravel layer

Statamic doesn't sit directly on PHP. Every request first goes through Laravel, and Laravel's own release schedule decides a lot about how exposed a Statamic site is. As Laravel News put it on release day, every PHP setup that serves web requests is affected: PHP-FPM, mod_php, php-cgi, FrankenPHP, and LiteSpeed. That covers essentially every way a Laravel app runs in production.

The Laravel team worked with the PHP Foundation ahead of time and posted per-platform status in its response updates. Laravel Cloud patched every running app in place on release day. Forge and Vapor customers had to install or deploy the fix themselves, as the hosting table below shows.

The Laravel version also sets the PHP ceiling and floor. Statamic 6 runs on Laravel 12 or 13. Laravel 13 needs PHP 8.3 or newer and gets security fixes until March 2028; Laravel 12 accepts 8.2 to 8.5 and is covered until February 2027. Statamic 5 sites can still be on Laravel 10 or 11, both past their security window, which is one more reason they belong on the upgrade list.

Stephen Rees-Carter's running security notice on Securing Laravel was the most useful live source that day. One tip from it is worth keeping for next time: install every other pending update before the patch drops, so the fix is the only change going out.

What the Statamic team did

Statamic didn't publish a blog post, but it did react. Early on October 21, Jack McDade announced in the Statamic Discord that statamic.com had been taken offline as a precaution until the PHP release at 14:00 GMT and the time needed to install it. License validation was expected to keep working in the meantime, and control panels on customer sites shouldn't be affected.

That is the same precaution recommended further down for client sites: if you can't patch yet, keep requests away from PHP. It also answers a question some agencies asked that morning. A Statamic site doesn't stop working because statamic.com is unreachable for a few hours.

Which Statamic sites can actually be patched

PHP only ships official fixes for 8.2 and newer, so the question for each site is which PHP versions its Statamic release allows. Statamic's support policy lists the ranges and dates:

Statamic 6 is the row that stands out. Its January 2026 release dropped PHP 8.2 and Laravel 11 entirely. In hindsight that was a very good call: no Statamic 6 site can sit on an unfixed PHP branch, and every branch it supports gets security fixes at least as long as Statamic 6 itself. For comparison, Craft 5 still allows PHP 8.2, and WordPress 7.0 officially runs on 7.4.

Statamic 5 is the row to watch. From January, a Statamic 5 site on PHP 8.2 sits on two unsupported layers at once: the next PHP emergency won't cover its engine, and the next Statamic advisory won't cover its CMS. That is why the upgrade belongs in this quarter's plan.

Who updates PHP for your site

Statamic has no first-party hosting, so the answer depends entirely on the Laravel or hosting setup underneath. A quick map:

Two details trip people up. Forge's automatic security updates do not cover PHP, because Forge installs it from a separate repository. And distributions often backport fixes without changing the version number, so php -v showing an older patch level on Ubuntu or Debian doesn't prove much. The package changelog does.

Restarting matters because long-running processes keep the old engine in memory until they stop. On a Statamic site, the one most often forgotten is the queue worker: Statamic 6 warms the static cache in the background through the queue. php artisan queue:restart takes care of it.

What to do while you can't patch yet

One Laravel habit doesn't help here: php artisan down. Maintenance mode is handled by PHP itself, so every request still reaches the vulnerable engine. If you need to buy time, block traffic before it reaches PHP instead: a firewall rule, a web server rule that only lets your own IP through, or a WAF in front. Cloudflare deployed emergency rules across its network for exactly this case. Clients rarely enjoy a few hours of downtime, but it's a much smaller bill than rebuilding a server someone else has been running code on.

Two practical notes from release day. Cloudflare's emergency rules were active for free plans, but on some paid plans the managed rule had to be switched on manually in the security rules dashboard. And if you look after many Forge servers, the Forge API can push PHP updates per server, which beats clicking through a fleet one dashboard at a time.

What Statamic's architecture changes, and what it doesn't

Static site generation helps the most. A site built with Statamic's SSG package is a folder of HTML files. The Dutch NCSC lists the Statamic static site generator as not vulnerable, because PHP only runs at build time. The machine that builds the site still runs PHP, and so does any control panel your editors use, so patch those. Forms, search, or preview features on a live PHP server need the same fix.

Full static caching helps less than it seems. With the full measure strategy, the web server delivers cached pages straight from disk without touching PHP. But every uncached URL, every query string, every form post, and every control panel request still reaches index.php. An attacker picks the request, so static caching lowers load, not exposure.

Flat files change what's at stake, not whether you're exposed. Without a database there is no table to dump, but the attack runs code on the server, and researchers at the cloud security company Wiz showed that PHP memory can leak passwords, tokens, and API keys. On a Statamic site that means everything in .env, including APP_KEY and mail or API credentials. If your logs from October 17 onward show odd multipart requests or memory exhaustion errors, rotate those secrets. If your content lives in git, a diff against the repository is a quick way to check that no templates or content files were changed.

The release process helps. Statamic publishes exact PHP ranges and end dates for every major version, ships security fixes through GitHub advisories, and keeps the requirement bumps aligned with Laravel. Statamic 7, planned for early 2027, will need PHP 8.4 or newer. Sites that already treat minor updates as routine will take that step, and the next PHP emergency, without much drama.

Who pays for the engine

php2shell sat unfixed for two years not because nobody cared, but because too few people understand PHP's engine well enough to change it safely. That work is funded by the PHP Foundation and done by a handful of developers. Laravel, Statamic, and every addon we ship depend on it. If your agency builds Statamic sites for a living, a PHP Foundation sponsorship is a small line in the budget for the layer everything else stands on.