Critical PHP Security Fixes: Update PHP on Your Grav Sites

The PHP security team released fixes for two critical vulnerabilities on Wednesday 21 October. Both are rated 9.2 out of 10, and both let an attacker run their own code on your server without logging in. Every Grav site runs on PHP, so I wanted you to hear it from us rather than find it in a hosting changelog a month from now.

This is not a Grav issue. It's a PHP issue, and the fix is in PHP itself. So the thing to update is PHP, on every server that runs one of your sites.

What's affected

• CVE-2026-109618, "RCE via OOM corruption". When PHP runs out of memory partway through handling a request, it can leave half-built data behind, and the cleanup that follows trusts it.
• CVE-2026-109619, "RCE via stale global state". Some data from one request can outlive the memory behind it, and the next request handled by the same PHP worker can pick it up.

Every PHP setup that serves web pages is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Apache with mod_php is the worst off. There, a working attack has been shown that needs nothing more than one request, before Grav or any other code even starts.

The fixed versions

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

PHP 8.1 and older get no fix from the PHP project. If one of your sites is still on one of those versions, this is the push to move it to a supported version.

What to do

1. Update PHP to the fixed version for your branch as soon as your host ships it. Check the version your site really runs, in your hosting control panel or with phpinfo(), not php -v on the command line, which is often a different PHP.
2. Restart PHP after the update. PHP-FPM keeps running the old code until it restarts, so the update alone doesn't protect you. Most hosts and package managers do this for you, but it's worth checking.
3. Running Grav in Docker? The official getgrav/grav images were rebuilt on 21 October with the patched PHP, on every tag. Pull the image again and recreate your container.

And always backup your site before you switch PHP versions. It takes a minute and saves a bad afternoon.

If you can't update today

There's one setting that blocks the most dangerous attack path on PHP-FPM (CVE-2026-109619), and I'd turn it off now. It's what we applied on the servers we run before the patched builds arrived. Add this to your php.ini (or your FPM pool config) and restart PHP:

session.upload_progress.enabled = 0

Grav doesn't use upload progress, so turning it off won't break your site. It has to go in php.ini or the pool config, because .user.ini files and ini_set() don't work for this one. On PHP 8.5, also set fatal_error_backtraces = 0.

But this only narrows the risk. The PHP team is clear that updating is the only complete fix. Honestly, I'd leave upload progress off even after you update. Grav never uses it, and attackers are going to be poking at it for a while.

Stuck on PHP 8.1 or older?

• Look for a patched build from whoever supplies your PHP. Linux distributions and long-term support vendors received the patches in advance, and some will ship backported fixes for 8.1 and older (Ubuntu Pro/ESM, Red Hat, CloudLinux's alt-php on shared hosts, and paid LTS vendors are the usual places). The PHP team also published minimal source patches for PHP 7.4, 8.0 and 8.1 for people who build PHP themselves.
• On CentOS, Rocky or Alma with Remi's repository (rpms.remirepo.net), the PHP team's advice is to switch to your distribution's packages or build from source, because that repository wasn't updated on release day.
• Keep post_max_size low. PHP recommends 8M for sites without file uploads, and 32M where uploads are needed. Grav's admin uploads media, so 32M is the realistic figure. Keep upload_max_filesize below it, and limit request size in the web server too, for example nginx's client_max_body_size.
• Prefer PHP-FPM over Apache mod_php. The proven attack that needs no help from the site only works on mod_php. On a cPanel host, that means choosing PHP-FPM as the handler in MultiPHP Manager if your host offers it.
• pm.max_requests = 1 on PHP-FPM, for small, low-traffic sites. Every PHP worker then exits after one request, so a request can never pick up leftovers from an earlier one. It costs more CPU, which is fine for a brochure site and too slow for a busy one.

The PHP team also lists memory_limit = -1 as a defense against CVE-2026-109618. I'd only use it on a server with a container or cgroup memory limit in place, because on Grav one heavy image resize could then eat all of the server's memory.

Grav and PHP 8.3

Grav 1.7 runs fine on PHP 8.2 and 8.3, as long as you're on the latest 1.7 release, so update Grav first and then switch PHP. Grav 2 already requires PHP 8.3 or newer, so if you've made the move to Grav 2 you're on a supported version and only need the patched build.

The full advisory is on php.net. If anything misbehaves after the switch, come and tell us on Discord at chat.getgrav.org. Someone there will help you sort it out.

— Andy