Two critical, unauthenticated remote code execution vulnerabilities in PHP core, CVE-2026-109618 and CVE-2026-109619 (reported CVSS v4.0 9.2), were patched in an emergency PHP release on October 21, 2026. The fix shipped across every supported branch at once: PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. A proof-of-concept (“PHP2Shell”) leaked before the release and public exploitation is expected, so the patch gap is the whole game. If you run PHP anywhere network-facing, update to the fixed release now, then confirm nothing was compromised during the exposure window.
Updated October 24, 2026: added a quick way to check whether you are affected, including the Linux distribution backport catch that makes a bare version number misleading, a direct answer on the public PHP2Shell proof-of-concept, and a plain answer on the session.upload_progress question. The confirmed fixed versions and the official advisory are reflected throughout. Originally published October 20 ahead of the release, and updated October 22 when the official patch shipped.
Correction: the widely shared mitigation, disabling session.upload_progress, does not fix this. The official fix is a core “state corruption via bailout” issue (GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp), and the only real remedy is upgrading to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12.
The one-paragraph version
PHP’s security team shipped an out-of-band release on October 21, 2026 that fixes two critical remote code execution bugs in PHP core. The official changelog records the fix as GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, described as a core “state corruption via bailout” issue, and the patched builds are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Both issues are unauthenticated, meaning an attacker who can reach a PHP application over the network could run code as the PHP process without logging in. A proof-of-concept tool called “PHP2Shell” surfaced before the release and at least one security firm said it reproduced one of the flaws, so any server that sat exposed and unpatched should be treated as potentially hit. The action is simple and urgent: upgrade to the fixed release for your branch, reload the runtime, verify with php -v, and then hunt for signs of compromise.
“The dangerous part of this one isn’t the bug, it’s the bad advice. Thousands of teams turned off session.upload_progress and think they’re covered. They’re not. The fix is a core engine patch. If you haven’t upgraded PHP, you’re still exposed.”
Sandeep Kamble, Founder and CTO, SecureLayer7
What is confirmed
These points come from the PHP project’s own release and changelog, cross-checked against independent reporting.
| Item | Confirmed detail |
|---|---|
| CVE IDs | CVE-2026-109618 and CVE-2026-109619. php.net records the fix as GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp |
| Severity | Reported CVSS v4.0 9.2 (critical) for both |
| Class | Remote code execution in PHP core, a “state corruption via bailout” flaw per the official changelog |
| Authentication | Unauthenticated (no login required) |
| Patch | Released October 21, 2026 as PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 |
| Fix location | Update PHP at the server or runtime level. It cannot be fixed in application code |
| Exploit status | A PoC (“PHP2Shell”) is public. Treat exposed, unpatched servers as at risk |
Fixed versions: upgrade to at least these
All four releases came out on October 21, 2026. Any release below the fixed version in its branch is affected.
| PHP branch | Patched release |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 and earlier | End of life. No official fix. Move off it or isolate it |
A few things follow directly from these facts. PHP runs almost everywhere web content does, through mod_php under Apache, PHP-FPM behind Nginx or Apache, or the CGI and CLI SAPIs. A core RCE therefore touches the long tail of the web: WordPress, Laravel, Drupal, Joomla, Magento, Shopware, WooCommerce, and countless custom apps. The fix ships as new PHP binaries, so the people who need to act are whoever controls the PHP runtime: your platform team, your managed host, or your container base images. Application developers cannot patch this from inside their codebase.
Why this is a patch-now, not a patch-soon
Normal PHP point releases are low drama. This one is different for three specific reasons.
First, the embargo broke before the patch. The coordinated-disclosure model assumes defenders get the fix before attackers get the details. That assumption failed on October 20, when the details leaked early. Attackers and defenders got roughly the same information at the same time, and attackers do not have a change-approval process.
Second, a working exploit is in circulation. A proof-of-concept called PHP2Shell leaked ahead of the release, and now that the fixed source is public, anyone can diff it against the vulnerable source to derive a reliable exploit. The fix and the full exploit effectively arrive together, which is exactly why an unpatched server is a live target rather than a theoretical one.
Third, history rhymes. The last PHP core RCE that mattered at this scale, CVE-2024-4577 (the PHP-CGI argument-injection bug), went from disclosure to automated mass scanning and ransomware deployment within days, and botnets were spraying it within about 24 hours. Plan for that tempo or faster.
Is there a public exploit? The PHP2Shell proof-of-concept
Yes. A proof-of-concept tool known as PHP2Shell surfaced on October 20, 2026, a day before the official patch, and at least one security firm said it reproduced one of the two bugs. PHP2Shell demonstrates the impact that makes this critical: unauthenticated remote code execution against a reachable PHP application. That is why it is treated as a live threat, not a theoretical one.
Working exploits are now a safe assumption for two reasons. The PoC leaked before the fix, and once the patched source went public anyone can compare it against the vulnerable source and rebuild a reliable exploit from the difference. You do not need to find the exploit to be at risk. You need only to be unpatched and reachable.
SecureLayer7 does not publish or link weaponized exploit code for an actively targeted, unauthenticated RCE, and you should be wary of “PHP2Shell” downloads on unofficial pages, since several circulating copies are themselves malware. The takeaway is defensive and simple: if a server was internet-facing and unpatched after October 21, treat it as potentially compromised and move to the compromise hunt below. For the authoritative affected and fixed versions, go to php.net, not to the PoC.
Who is exposed
If you run PHP anywhere that accepts network traffic, assume you are in scope until proven otherwise.
- Internet-facing PHP apps are the first targets: public WordPress, Magento, Laravel, and custom PHP sites, plus any admin panel, API, or webhook endpoint that a PHP interpreter serves.
- The CMS and e-commerce long tail matters because so much of it runs unattended. A large share of PHP in the wild sits on shared hosting and older stacks that nobody actively maintains.
- End-of-life PHP is the hard problem. The fix landed in the 8.2, 8.3, 8.4, and 8.5 branches. Servers on PHP 8.1, 7.x, or 5.x are end of life and will very likely never receive an official patch. Independent estimates put the number of internet-facing hosts on unsupported PHP versions in the high hundreds of thousands (one estimate cites roughly 884,000). Those systems need a different plan: a distribution backport, a virtual patch, isolation, or decommissioning.
Are you affected, and how to check
You are affected if any PHP runtime you operate is below the fixed release for its branch (8.2.35, 8.3.36, 8.4.27, or 8.5.12) and can be reached, directly or indirectly, by untrusted input. The fastest check is to read the running version on each host and compare it to the table above.
php -v # CLI version
php-fpm8.3 -v # the PHP-FPM binary actually serving traffic
apachectl -M 2>/dev/null | grep php # is mod_php loaded?One important catch on Linux. On Debian, Ubuntu, RHEL, AlmaLinux, and Rocky, the distribution backports the security fix into its own PHP package and usually keeps the upstream version number, raising only the package revision. So php -v can read a number below the fixed release and still be patched, and it can read a “high enough” number and not be, depending on when the host last updated. Do not judge a distribution-packaged PHP by the php.net version alone. Confirm the fix against your distribution’s security tracker for this CVE:
If you compiled PHP yourself, installed it from a third-party repository such as Sury or Remi, or baked it into a container image, the distribution backport does not apply. You are on the upstream version and must be at or above the fixed release. Check every image tag and rebuild, because a running container keeps its old PHP until you redeploy it.
Does disabling session.upload_progress fix CVE-2026-109618?
No. Setting session.upload_progress.enabled = Off was a pre-patch guess at the root cause, and it does not stop these bugs. The official fix is a core “state corruption via bailout” issue (GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp) that the changelog does not tie to upload progress. The only reliable remedy is upgrading PHP to 8.2.35, 8.3.36, 8.4.27, or 8.5.12.
What to do now
This is the core of it. Order matters: do the inventory and isolation first, because you cannot patch or defend what you have not found, then upgrade everything.
1. Inventory every PHP runtime you own. You are looking for the interpreter, not just the apps.
php -v # on each host
dpkg -l | grep -i php # Debian/Ubuntu
rpm -qa | grep -i php # RHEL/Alma/Rocky
find / -xdev -name 'php*' -type f 2>/dev/null # catch unmanaged buildsDo not forget container images, CI runners, serverless layers, appliance firmware, and that one legacy box. A dedicated asset-inventory or attack-surface tool can surface every PHP instance across the estate in one pass.
2. Find and flag everything internet-facing. External PHP is the priority queue. PHP services usually give themselves away with an X-Powered-By: PHP/x.y.z response header or a PHPSESSID cookie. Your external attack-surface tooling, or a quick scan for those signatures, will rank what to protect first.
3. Upgrade to the fixed release now. This is the only real fix. Move every PHP runtime to at least 8.2.35, 8.3.36, 8.4.27, or 8.5.12 for its branch, then reload. For PHP-FPM that is the package upgrade plus a systemctl reload php*-fpm; for mod_php it is a graceful Apache restart. Confirm with php -v on every host that it actually moved, because a reload that silently kept the old worker is the classic way to think you patched when you did not.
# Debian/Ubuntu example (adjust the branch to yours)
apt-get update && apt-get install --only-upgrade 'php8.3*'
systemctl reload php8.3-fpm
php -v # must show 8.3.36 or newer4. Make a plan for the systems that will not get a fix. For end-of-life PHP (8.1 and older) there is no upstream patch coming. Options, roughly in order of preference: move to a supported branch today if the app will tolerate it; ask your hosting provider or distribution whether they will backport; put the app behind strict network controls; or take it offline until you can do one of the above.
5. Ignore the upload-progress “mitigation.” Before the patch, a stopgap circulated suggesting you disable the upload-progress feature:
session.upload_progress.enabled = Off # NOT a reliable fix for this bugNow that the release is out, be clear about what that was: an unverified guess at the root cause. The official changelog records the fix as a core “state corruption via bailout” issue (GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp) and does not tie it to upload progress at all. Disabling that setting is cheap and harmless if you rarely use the feature, but do not treat it as protection. The fix is to update PHP.
6. Use a WAF as a speed bump, not the fix. A WAF or reverse proxy can buy time, and rate-limiting or blocking large multipart POSTs to endpoints that do not accept uploads is a reasonable hardening step. But memory and state-corruption RCEs are frequently reachable in ways that signature rules miss. Deploy real vendor rules the moment they ship, and still patch the runtime.
7. Raise the floor on detection and recovery. Snapshot or back up internet-facing PHP hosts so you have a known-good baseline. Turn up web-server and PHP-FPM logging. Make sure you can answer “what new files appeared in my webroot today,” because the end goal of this exploit class is almost always a webshell.
An AI prompt to check and fix your PHP
If you want to move faster, paste the prompt below into a capable AI assistant such as Claude or ChatGPT. It turns the steps above into a guided triage: it works out whether each host is affected, gives you the exact upgrade commands for your operating system and install source, and hands you a post-patch compromise checklist. It is written to stay defensive and will not produce exploit code. Two rules before you use it: do not paste secrets, credentials, or internal hostnames into a third-party AI, and read every command it returns before you run it, checking the versions against php.net.
You are a senior incident-response engineer. Help me remediate the critical
PHP core remote code execution vulnerabilities CVE-2026-109618 and
CVE-2026-109619, fixed by the PHP project on 21 October 2026 in PHP 8.2.35,
8.3.36, 8.4.27, and 8.5.12 (php.net advisories GHSA-w8hw-w9fx-j79w and
GHSA-6wmf-4rv5-p3rp, a core "state corruption via bailout" flaw). Work
defensively only: do not write or suggest exploit code or proof-of-concept
payloads.
First, ask me for:
- the output of `php -v` on each host, and the SAPI in use (PHP-FPM, mod_php,
CGI, or CLI)
- the operating system and version (for example Ubuntu 22.04, Debian 12,
RHEL / Alma / Rocky 9)
- where PHP came from: the OS repository, a third-party repository such as
Sury or Remi, a Docker image, or a managed / cPanel host
- which hosts are internet-facing, and what sits in front (Nginx, Apache,
a WAF or CDN)
Then, for each host:
1. Tell me whether the installed version is vulnerable by comparing it to the
fixed releases above. Anything below the fixed version in its branch is
affected. PHP 8.1 and earlier are end of life and will not get a fix.
2. Give me the exact copy-paste upgrade-and-reload commands for my specific OS
and install source, then show me how to confirm with `php -v` that the
running workers actually moved to the fixed version.
3. For any end-of-life PHP, give a prioritized fallback: move to a supported
branch, request a distribution backport, isolate behind strict network
controls, or decommission.
4. State plainly that disabling session.upload_progress is not a reliable fix
for this bug, and that upgrading is the only real remedy.
5. Give me a short post-patch compromise-hunt checklist for my stack: new or
modified PHP files in the webroot, webshell signatures, unexpected outbound
connections, and new CMS admin accounts.
Prioritize internet-facing hosts first, and ask me to clarify anything
ambiguous before giving commands.After you patch: hunt for compromise
The official fix is out, so go to the source, not the rumor mill: php.net’s security announcements and changelog and the php-src GitHub security advisories carry the authoritative affected and fixed versions. Once you have confirmed every host is on the fixed release and reloaded, switch from patching to hunting, because anything exposed during the gap could already be compromised. Look for PHP files created or modified around the disclosure window, odd files in upload and cache directories, and web-shell signatures:
find /var/www -type f -name '*.php' -newermt '2026-10-20' 2>/dev/null
grep -rlE 'eval(|base64_decode(|assert(|system(|passthru(|shell_exec(' /var/www 2>/dev/nullReview outbound connections from web servers (callbacks and reverse shells), check for new admin users in your CMS, and rotate secrets that lived on any host you cannot prove stayed clean.
Frequently asked questions
The fix shipped on October 21, 2026 in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Any release below those in its branch is affected, so upgrade to at least the fixed version for your branch. PHP 8.1 and earlier are end of life and will not receive an official fix, so treat them as permanently vulnerable and move off them. php.net records the fix as GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.
No. A stopgap circulated before the patch suggesting you set session.upload_progress.enabled = Off, but the official fix is a core “state corruption via bailout” issue and the changelog does not tie it to upload progress. Disabling that feature is not a reliable mitigation. Update to the fixed release instead.
Potentially, in blast radius. Like Log4Shell, it is an unauthenticated RCE in a component that is deployed almost everywhere, so the population of vulnerable systems is enormous. The key difference is that the fix is a straightforward runtime upgrade rather than a hunt through transitive dependencies. The exploit leaking before the patch compresses the defender timeline rather than widening it.
A proof-of-concept tool called PHP2Shell leaked before the release, and at least one firm said it reproduced one of the two bugs. Now that the patched source is public, anyone can diff it to derive a reliable exploit, so assume working exploits exist. Do not download exploit bundles from unofficial pages.
Treat a WAF as temporary mitigation only. It may block some attempts and buy a few hours, but memory and state-corruption bugs are hard to filter reliably. Patch the runtime.
Assume you will not get an official fix. Move to a supported branch, get a backport from your distribution or host, isolate the system behind strict network controls, or take it offline. Do not leave an unpatched, internet-facing, end-of-life PHP server up.
Treat it as exploited. A weaponized proof-of-concept is public and the patched source reveals the bug. Even without confirmed in-the-wild reports in front of you, the safe assumption after October 21 is that unpatched, exposed servers are being targeted.
Yes, as an accelerator, not an authority. This post includes a ready-to-paste prompt that guides an AI assistant through checking whether your PHP is affected, generating the exact upgrade commands for your platform, and producing a post-patch compromise checklist. Do not paste credentials or internal details into a third-party AI, and verify every command and version against php.net before running it. The fix itself is always the same: upgrade to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12.
Disclosure timeline (UTC)
- 2026-10-20, ~15:20: An unverified Hacker News post warns of two incoming PHP RCE CVEs. Details of the flaws begin leaking ahead of the embargo.
- 2026-10-20: The PHP project confirms an emergency security release for the following day; an independent security firm says it reproduced one of the bugs; CERT-EU issues an alert advising isolation of internet-facing PHP apps where immediate patching is not feasible; the PHP2Shell tool surfaces.
- 2026-10-21, 14:00: PHP security release published. Fixed versions are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12; the changelog records the fix as GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp (“avoid state corruption via bailout”).
- 2026-10-22: This post updated with the confirmed fixed versions and the official advisory, and the pre-patch upload-progress mitigation corrected.
- 2026-10-24: Added an affected-or-not self-check with the Linux distribution backport caveat, a dedicated answer on the public PHP2Shell proof-of-concept, and a direct answer on the session.upload_progress question.
The honest bottom line
The fix is out. Two unauthenticated, critical RCEs in PHP core are patched in 8.2.35, 8.3.36, 8.4.27, and 8.5.12, and a leaked exploit means the patch gap is where the risk lives. Upgrade every PHP runtime to the fixed release for its branch, verify with php -v, and then hunt the systems that were exposed before you patched, because those are the ones that could already be compromised. End-of-life PHP (8.1 and older) will not get a fix, so move off it or isolate it. Skip the upload-progress “mitigation”; it was never the fix.
If you want help finding every PHP runtime across your external attack surface, or validating that your exposed applications are actually patched and not already compromised, that is the kind of exposure work SecureLayer7 does.
Sources and further reading
- PHP project security releases and announcements (php.net)
- PHP 8 ChangeLog, including the 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 security fixes (php.net)
- CVE-2026-109618 – MITRE CVE record
- CVE-2026-109619 – MITRE CVE record
- CERT-EU Security Advisory 2026-018
