PHP security release of October 2026

PHP released a critical security update today. The Bref 3 layers and Docker images with the patched PHP versions are already published in all regions.
Update your applications now:
composer update bref/bref -WThen redeploy. That’s it for most applications, the details are below. (-W lets Composer update Bref’s own dependencies too, without it the update can fail.)
What happened
Yesterday, the PHP team announced a critical security release for today at 14:00 UTC: two vulnerabilities, rated 9.2 on the CVSS scale. The release came out a bit earlier, at 13:35 UTC: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35Â .
The two vulnerabilities:
- CVE-2026-109618: remote code execution through state corruption when PHP runs out of memory while starting a request or parsing its body. Multipart requests can trigger it, whatever your application code does.
- CVE-2026-109619: remote code execution through state left behind by a request and used by the next request on the same worker. Session upload progress is one confirmed path, validated on PHP-FPM.
PHP lists PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed as affected. And their advisory is very clear: “there are no complete mitigations, updating is the only safe choice”.
PHP 8.1 and older are end of life and don’t get a fix. If you still run one of those, upgrade to PHP 8.2 or later.
What’s updated in Bref
PHP was released at 13:35 UTC. The pull requests to update the Bref layers were opened at 13:37, CI was green at 13:59, and the new layers and Docker images were published in every region at 14:06. That’s 31 minutes after php.net.
That was fast because we prepared everything in advance: the scripts to bump PHP versions were ready and the build cache was warm. All that was left was to wait for PHP, open the PRs and publish.
The new Bref 3 layers (x86 and ARM, all regions):
| PHP | Layer version |
|---|---|
| 8.5 | php-85:21 |
| 8.4 | php-84:24 |
| 8.3 | php-83:24 |
| 8.2 | php-82:26 |
bref/bref 3.0.14 is on Packagist and uses these layers.
The Docker images are updated too: bref/php-82 to bref/php-85, bref/arm-php-82 to bref/arm-php-85, as well as the bref/php-8x-dev and bref/build-php-8x images. The 3, 3.0.10 and latest tags point to the new versions.
Bref 2
The Bref 2 layers are published too (version 2.3.45, PHP 8.2 to 8.4), one hour after php.net:
| PHP | Layer version |
|---|---|
| 8.4 | php-84:43 and php-84-fpm:43 |
| 8.3 | php-83:71 and php-83-fpm:71 |
| 8.2 | php-82:115 and php-82-fpm:115 |
bref/bref 2.4.22 uses these layers: run composer update bref/bref -W and redeploy, same as for Bref 3. The v2 Docker images (bref/php-8x-fpm:2, bref/php-8x:2 and bref/php-8x-console:2) are updated as well, the 2 and 2.3.45 tags point to the new PHP versions.
Bref 1 layers will not be rebuilt: Bref 1 is not maintained anymore. If you are still on Bref 1, now is a good time to upgrade.
How to update
With layers (serverless.yml)
Update Bref to 3.0.14 or later, and redeploy:
composer update bref/bref -W
serverless deployIf you use layer ARNs directly instead of the Bref runtimes (e.g. runtime: php-84-fpm), get the new ARNs on runtimes.bref.sh .
With Docker images
Your Docker cache still has the old base images with the old PHP version. Pull them again when building, then push the image and redeploy:
docker build --pull -t my-app .(or run docker pull bref/php-84:3 before building)
With Bref Cloud
If you deploy Laravel applications with Bref Cloud, they will get the new layers on their next deploy once Bref Cloud is updated later today.
Check that it worked
The function should use the new layer versions listed above:
aws lambda get-function-configuration --function-name my-function --query LayersYou can also check the PHP version with php -v, or in the X-Powered-By HTTP header: it should be 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
Which functions are affected?
The PHP-FPM runtime is squarely in scope: that’s the php-84-fpm runtime (or BREF_RUNTIME=fpm), used for web applications with Laravel, Symfony, etc. Update these first.
The function runtime, Laravel Octane, console commands and queue workers run php-cli in a single long-lived process. They are not in the attack paths described by PHP:
- the CLI SAPI doesn’t parse request bodies itself: Bref parses multipart requests in PHP code
- a fatal error or running out of memory ends the process
Update them anyway. The fix is in the Zend engine itself, and every layer was rebuilt. composer update bref/bref -W updates all your functions at once, so there is nothing extra to do.
What about mitigations?
I don’t recommend any mitigation instead of updating. Here is why:
session.upload_progress.enabled=0only covers part of one of the two vulnerabilities (PHP says so in the advisory).file_uploads=Offandpost_max_sizedo nothing here.
If you need a few hours before you can deploy and your application doesn’t handle file uploads, blocking multipart requests in your WAF or CDN can help as a stopgap. But then update.
Thanks
Thank you to the PHP security team for the fix and the release, and to the people who reported these vulnerabilities (Wiz, lcfr-hax and others, see the advisory ).
The Bref layers are built on Depot , a Bref sponsor: their remote builders and shared build cache are what made the builds this fast today. Without them we couldn’t have reacted this quickly to the release. Thank you Depot, it really made a difference.
Thank you to the companies that sponsor Bref:
Premium sponsors:
Gold sponsors:
And thank you to everyone sponsoring on GitHub .
Days like today are possible thanks to the companies and people who sponsor Bref. If Bref matters to your company, consider sponsoring the project.