Critical PHP security fixes are out: update PHP on your Grav sites

Hi,

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 me rather than find it in a hosting changelog a month from now.

This is not a Grav issue specifically. 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. The PHP team did publish small source patches for 7.4, 8.0 and 8.1, but they only help if you build PHP yourself. If one of your sites is still on one of those versions, these vulnerabilities are proof you should move to a supported version ASAP.

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. Get a patched build without changing PHP versions. This is the only real fix for anyone stuck below 8.2.

• From the operating system: Linux distributions and long-term support vendors received the patches in advance, and some will ship backported fixes for 8.1 and older. Check with whoever supplies your PHP (Ubuntu Pro/ESM, Red Hat, CloudLinux's alt-php on shared hosts, and paid LTS vendors are the usual sources).
• From source: the PHP team published minimal backport branches for 7.4, 8.0 and 8.1 for people who build PHP themselves.
• Remi's repository: anyone on CentOS, Rocky or Alma who uses rpms.remirepo.net won't get an update today. PHP's advice is to switch to the distribution's packages or build from source.

3. Keep post_max_size low (CVE-2026-109618).

   • 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 body size in the web server as well, for example nginx's client_max_body_size.

4. Prefer PHP-FPM over Apache mod_php. The proven attack that needs no help from the site only works on mod_php, and FrankenPHP is likely affected the same way. The other routes on FPM need a fatal error the attacker can trigger, which is much harder. On a cPanel host, that means choosing PHP-FPM as the handler in MultiPHP Manager if the host offers it.

5. memory_limit = -1. I'd recommend this only with a warning.

   • It's PHP's main setting-based defense against CVE-2026-109618, because -1 means there's no per-request memory cap to run out of.
   • On Grav, one heavy image resize could then use all of the server's memory, so it only makes sense on a VPS with a container or cgroup memory limit in place.
   • It has to be set as php_admin_value so nothing can lower it again.
   • Never use RLIMIT_AS or RLIMIT_DATA instead. They trigger the vulnerable code.

6. 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 find leftover data from an earlier one. That shuts out 109619's routes at the cost of more CPU, which is fine for a brochure site and too slow for a busy one.

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 the setting we applied on the sites we host. 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.

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. 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.

Trilby Media Hosted Clients

Quick word about clients of ours that we host. I rolled out the mitigating php.ini solution immediately, and am in the process of updating the PHP versions as you receive this. Every site was already migrated to PHP 8.3 yesterday when I became aware of the upcoming security patches to ensure every site would benefit. If you notice any new warnings or deprecated notices on your site, please contact me and I'll get those resolved ASAP.

Thanks,

— Andy