Introduction
On 21 October 2026, the PHP project shipped an emergency security release for every supported branch. It fixes two vulnerabilities, each rated CVSS v4.0 9.2, that allow unauthenticated remote code execution. There is no partial workaround and no configuration that makes you safe. The only fix is to update.
If your business runs anything on PHP — a corporate website, an e-commerce store, a customer portal, an internal ERP, a WordPress or Laravel application — this is the kind of advisory that deserves attention today rather than at the next maintenance window. This article explains what was disclosed, who is actually exposed, what a correct patch looks like in practice, and where most teams get it wrong.
What Was Disclosed
The PHP security team pre-announced the release on 20 October and published it on 21 October 2026. Two separate issues were fixed:
- CVE-2026-109618 — remote code execution through out-of-memory corruption.
- CVE-2026-109619 — remote code execution through stale global state.
Both are rated 9.2 on the CVSS v4.0 scale, and both are described as exploitable without authentication. In plain terms: an attacker does not need an account, a password, or a valid session. They need to be able to send requests to your application.
Fixed Versions
The patched releases are:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Anything below those numbers on the matching branch is vulnerable. The PHP security team also published minimal source backports for PHP 7.4, 8.0 and 8.1 — branches that no longer receive regular updates — which tells you something about how seriously they rated the impact.
Why This Advisory Is Different
Plenty of PHP security releases fix issues that only matter in narrow conditions: a specific extension, an unusual function call, a configuration almost nobody uses. This one is not in that category, for three reasons.
1. It Affects Every Way of Running PHP
The advisory lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed as affected. That covers essentially every production deployment pattern in common use. The project singled out mod_php as the highest risk configuration — which is notable, because mod_php is still extremely common on older shared hosting and on servers that were set up years ago and have simply kept running.
2. There Is No Mitigation
Many advisories come with an interim measure: disable a function, change an ini setting, block a request pattern at the firewall. This one does not. The official guidance is that updating is the only safe option. A web application firewall may reduce opportunistic scanning, but it is not a substitute for the patch.
3. No Authentication Is Required
Pre-authentication RCE is the highest-value class of vulnerability for attackers because it can be weaponised into automated, untargeted scanning. Within days of a disclosure like this, mass scanning for unpatched hosts becomes routine background noise on the internet. You do not need to be a notable target to be hit; you only need to be reachable and behind.
Who Is Most Exposed Right Now
In our experience, the organisations caught out by advisories like this are rarely the ones with no security practice at all. They are usually organisations where PHP is running somewhere nobody is actively watching. Typical cases:
- Servers set up years ago that "just work." A VPS configured in 2019 with Apache and mod_php, still serving the corporate site, with no one assigned to its updates.
- Multi-site servers. One machine hosting eight or ten domains, where several PHP versions are installed side by side and only one of them is on anybody's radar.
- Mixed SAPI setups. A server where the command line runs one PHP version, Apache runs another through mod_php, and a third is installed for a legacy application. Patching one does not patch the others.
- Containerised applications. A Docker image built from a base tag months ago, redeployed unchanged ever since. The host may be patched; the container is not.
- Managed and shared hosting. Often patched by the provider — but "often" is not "verified," and the verification is your responsibility, not theirs.
What a Correct Patch Actually Looks Like
Running an update command is the easy part. Doing it correctly — and knowing afterwards that it worked — involves more steps than most teams expect.
Step 1: Inventory Before You Patch
Establish which PHP versions are installed, which ones are actually serving traffic, and through which SAPI. A server can easily have three PHP versions installed with only one of them exposed to the internet — or, worse, two of them exposed through different virtual hosts. Patching blind means patching incompletely.
Step 2: Patch Every Branch in Use
If both 8.2 and 8.3 are installed, both need updating. This sounds obvious and is the single most common omission we see. The CLI binary, the Apache module and the FPM service are separate packages; upgrading one leaves the others untouched.
Step 3: Restart the Right Services
A patched package on disk does nothing while the old code is still resident in memory. With mod_php, the Apache process must be restarted. With PHP-FPM, the FPM service must be restarted or reloaded. Skipping this leaves you fully vulnerable with a package manager that reports everything is up to date — a genuinely dangerous combination, because it looks like success.
Step 4: Verify Against Reality
Confirm the running version, not just the installed one. Check that the web server process has actually loaded the new module. Confirm there are no pending updates left on any branch. A deployment report is not evidence; a verified running version is.
Step 5: Check What Happened Before You Patched
This step is routinely skipped and it matters most on servers that were behind for a while. Patching closes the door; it does not tell you whether anyone came through it earlier. A reasonable post-patch review covers authentication logs for unexpected successful logins, scheduled tasks for unfamiliar entries, web roots for recently modified or unexpected PHP files, listening ports for services that should not be exposed, and file integrity against a known-good source.
Step 6: Look at What Else Is Behind
Servers that are behind on PHP are rarely behind on PHP alone. Accumulated kernel updates awaiting a reboot, stale container base images and expired or failing certificate renewals tend to travel together. An advisory is a good moment to deal with the cluster, not just the headline item.
The Deadline Behind the Headline
There is a second issue worth planning for now. PHP 8.2 reaches end of life on 31 December 2026. After that date it receives no security fixes from the PHP project at all.
The 8.2.35 release patches today's vulnerabilities, but it does not change that deadline. Any application still on 8.2 in January 2027 will be permanently exposed to every subsequent PHP vulnerability, with no official patch ever arriving. Given that 8.2 is still widely deployed, a large number of organisations are going to discover this the hard way.
The practical implication: if you are on 8.2, treat this advisory as the trigger for a planned migration to a supported branch, not just a patch. A migration done calmly over several weeks — with a compatibility review, a staging environment and a tested rollback — is a routine project. The same migration done urgently in January because a new critical CVE has landed on an unsupported branch is not.
Common Mistakes We See
Across the environments we maintain and audit, the same handful of errors recur after every major PHP advisory:
- Updating the CLI and assuming the web is covered. Checking the version on the command line is the usual way people verify, and it is the one SAPI that is almost never the one serving traffic.
- Forgetting the restart. Everything reports as patched; the vulnerable code is still running in memory.
- Assuming automatic updates handled it. Unattended upgrade tooling is frequently scoped to the distribution's own repositories and excludes third-party PHP repositories entirely.
- Patching the host but not the containers. Images need rebuilding with a refreshed base layer and the containers need recreating; restarting a container reuses the same old image.
- Trusting the hosting provider without verification. Many providers do patch quickly. Confirming it takes a minute and removes the assumption.
- Treating an upload report as proof. Whether it is a deployment or a patch, the evidence is the state of the live system afterwards.
How 4A Labs Can Help
4A Labs has been building and operating production software since 2011, for clients ranging from startups to enterprises across our offices in Miami, Istanbul, Ankara, Santiago, Lima and Bogotá. Keeping the infrastructure underneath those applications current is part of the work, not an afterthought — and it is something we also do for organisations whose applications we did not originally build.
If this advisory affects you, we can help with:
- Emergency patching. Identifying every PHP version and SAPI on your servers, applying the correct updates, restarting the right services and verifying the running state afterwards — with minimal, planned downtime.
- Exposure assessment. A clear answer to the question "are we actually vulnerable, and where," across every server, site and container you operate.
- Post-incident review. For servers that were behind for a while: an examination of logs, scheduled tasks, web roots, accounts and listening services to establish whether the gap was exploited before it was closed.
- PHP 8.2 end-of-life migration. Compatibility review, a migration plan with a staging environment, and execution on a schedule you choose rather than one an attacker chooses for you.
- Ongoing maintenance. Monitored, regularly patched infrastructure so the next critical advisory is a routine update rather than an emergency.
- Application-level hardening. Because keeping PHP current is necessary but not sufficient — configuration, access control, dependency management and deployment practice all matter.
Conclusion
Two unauthenticated remote code execution vulnerabilities, rated 9.2, affecting every common way of running PHP, with no mitigation available. The patch exists and is straightforward to apply. The risk lies in not knowing what you are running, patching incompletely, or forgetting the restart that makes the patch take effect.
The practical next steps are short: find out which PHP versions and SAPIs you are running, update every branch in use to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, restart the web server and FPM services, verify the running versions, and — if you were behind — check whether anything happened in the meantime. Then put 31 December 2026 in the calendar if any of your systems are still on 8.2.
If you would rather have someone handle that for you, or simply want a second pair of eyes confirming your systems are genuinely clean, get in touch with 4A Labs. We will tell you plainly what we find.