PHP security release of 21 October fixes two critical remote code execution bugs
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 close two flaws rated 9.2 that let anyone run code on a server without logging in. What changed, and why a patch on the day depends on who is watching.
On 21 October 2026 the PHP project released 8.5.12, 8.4.27, 8.3.36 and 8.2.35. All four fix the same two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, rated 9.2 out of 10. Both allow remote code execution without logging in: a request from the internet can make the server run the attacker's code. The PHP team wrote that there is no complete mitigation and that updating is the only safe choice.
Notice what that sentence leaves out. It does not say who updates your server. The release is public the moment it is announced, and so is the description of the flaw. From that hour, the only question is how long your site stays exposed.
The same day, or whenever someone notices
Picture two companies running the same PHP 8.4. In the first, someone who knows the system read the announcement on release day, checked the version on the server, updated the package, restarted PHP-FPM, tested the main pages and wrote down what was done. That takes well under an hour, and nobody else in the company hears about it.
In the second, the site was built by a developer who moved on, the server is looked after by nobody in particular, and the update is "something IT does". The announcement does not reach anyone with the access to act on it. The server keeps running, the site keeps working, and nothing looks wrong, because an unpatched flaw does not announce itself. The first sign of trouble is the trouble.
The software is identical in both cases. What differs is whether anyone is watching.
What to do today
- Check the version: php -v on the server, or the version your hosting panel shows.
- On 8.2, 8.3, 8.4 or 8.5: update to the patch above. Debian, Ubuntu and Red Hat packages were ready on release day.
- On 8.1 or older: the PHP project no longer ships updates for it. For this release the security team published minimal source patches for 7.4, 8.0 and 8.1, but that is a courtesy, not a plan.
- Restart PHP-FPM or the web server, then check the site.
Unsupported versions make the gap wider
On a supported version the fix arrives the same day and installs in minutes. On an unsupported one you wait for a vendor backport that may never come, or you build PHP from source and hope you did it right. PHP 8.2 reaches end of life on 31 December 2026. If that is what you run, the move to 8.4 belongs on this year's list.
Why a retainer exists
This is the situation the Maintenance Retainer is for. You buy a block of hours each month, from EUR 720 for 8 hours, excl. VAT. In those hours I watch the releases for the stack you run, patch it, check that backups restore, keep an eye on uptime and certificates, and send a short report each month. When a release like this one lands, the first step is mine, not yours.
If you do not know which PHP version you run, or who would update it, start with the security quick scan: 8 hours, EUR 720 excl. VAT, written report. It tells you what is exposed today.
The retainer is at /services/maintenance-retainer and the quick scan is at /services/security-assessment. Write to me through the contact form and I reply within one working day.
This article is about: Maintenance Retainer
More news: Customers now ask for AI on their own data: an MCP server in front of the API is the safe answer · PHP 8.2 reaches end of life on 31 December: a two-day Health Check shows where your system stands · all news