Today the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two vulnerabilities that let an attacker run code on a server without logging in. Both are rated CVSS v4.0 9.2.
Some of our customers run PHP on enum themselves. For others, we run their PHP applications as part of DevOps as a Service. This post covers what we did about it.
What the bugs are
- CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): if PHP runs out of memory while it sets up a request, it can stop with internal request data only half initialized. Cleanup then treats that data as valid.
- CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): internal state that belongs to one request can outlive the memory behind it. The next request on the same worker can use it before PHP resets it.
The advisory says every PHP installation that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. mod_php carries the highest risk. The listed workarounds only reduce the risk. In the advisory’s words, they “do not make an installation safe”.
What we did
1. We told every PHP customer
Before we changed anything, we contacted every DevOps as a Service customer running PHP. We also contacted the customers who run PHP on enum themselves, even though we don’t operate their applications. We told them a critical PHP security release was coming, recommended the same steps as below and offered to help them carry them out. A customer should hear about a critical bug in their stack from us, not from a news site.
2. We recommended taking the pages offline
On 20 October, the PHP project announced a critical security release for 21 October at 14:00 UTC: two vulnerabilities, both rated CVSS v4.0 9.2. Until then there was no fix to install. That left two options: keep the applications online and hope nobody exploits the bugs first, or take them offline before the release. We recommended taking them offline.
3. We helped put static fallback pages in place
An offline page doesn’t have to be an error page. Together with each customer, we put up a static page in place of the PHP application: who they are, how to reach them, and a note that the site is back shortly. A static page has no PHP, so it has nothing these bugs can reach.
4. We built our own images from the patch releases
Our customers run PHP in containers. When PHP released the fixed versions, there were no Docker images for them yet, so there was nothing we could pull. We built our own images from the patch releases.
5. We rolled out the patched images and brought the sites back
We deployed the new images and replaced the static fallback pages with the applications again. The sites are back online, running the fixed PHP versions.
If you run PHP yourself
- Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and restart every worker. A new package on disk doesn’t fix workers that are still running.
- If you run PHP in containers, check that your base image really has the fixed version. Don’t assume a rebuild picked it up: run
php -vin the running container. - PHP 8.1 and older no longer get releases from the PHP project. There are only source backports for 7.4, 8.0 and 8.1. If you’re on one of those, plan the upgrade now.
- PHP 8.2 reaches end of life on 31 December 2026.
- Until you’ve patched, apply the partial mitigations from the advisory on php.net and put the application behind a static page if you can.
If you’d rather have someone else handle this the next time it happens, that is what DevOps as a Service is for.