PHP RCE CVE-2026-109618 & 109619: What To Do Now

Two critical, unauthenticated remote code execution vulnerabilities in PHP core, CVE-2026-109618 and CVE-2026-109619 (both CVSS v4.0 9.2), will be patched in an emergency PHP release on Wednesday, October 21, 2026 at 14:00 UTC. The details leaked ahead of the embargo and a working exploit is already circulating, so the realistic planning assumption is mass exploitation within minutes of the patch going live. This is a patch-gap race. The window to prepare is now, before the fixed versions publish.

Last updated: October 20, 2026. This is a developing, pre-disclosure situation. Full technical details are embargoed until the October 21 release. We mark clearly what is confirmed and what is still unverified, and we will update this post once the official advisory is out.

The one-paragraph version

PHP’s security team has pre-announced an out-of-band release for 14:00 UTC on October 21, 2026 that fixes two critical remote code execution bugs in PHP core. Both are rated CVSS 9.2 and are described as unauthenticated, meaning an attacker who can reach a PHP application over the network could run code as the PHP process without logging in. On October 20 the details leaked early, a proof-of-concept tool called “PHP2Shell” surfaced, and at least one security firm said it reproduced one of the flaws. Because a weaponized exploit is in circulation before most servers are patched, defenders should treat the next 24 to 48 hours as an active incident-readiness window, not a routine patch cycle.

What is confirmed right now

These points are consistent across the PHP project’s own advance notice and multiple independent security vendors.

Item	Confirmed detail
CVE IDs	CVE-2026-109618 and CVE-2026-109619
Severity	CVSS v4.0 9.2 (critical) for both, per the PHP security team
Class	Remote code execution in PHP core
Authentication	Unauthenticated (no login required)
Patch	Emergency PHP security release, October 21, 2026, 14:00 UTC
Fix location	Update PHP at the server/runtime level. It cannot be fixed in application code
Status	No confirmed in-the-wild exploitation as of October 20, but a PoC (“PHP2Shell”) has leaked

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 minutes matter here, not days

Normal PHP point releases are low drama. This one is different for three specific reasons.

First, the embargo already broke. The coordinated-disclosure model assumes defenders get the patch before attackers get the details. That assumption failed on October 20. Attackers and defenders now have roughly the same information, and attackers do not have a change-approval process.

Second, a working exploit is in circulation before the patch. Security researchers tracking the threat expect mass attacks to start within roughly 15 minutes of the release. That is a forecast, not a measurement, but it is a sensible planning number. The patch itself is also a roadmap: the moment the fixed source publishes, anyone can diff it against the vulnerable source to derive the bug, so the fix and the full exploit effectively arrive together.

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.

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. PHP currently supports the 8.2 branch and later. If the affected range really does reach back to 5.4, then servers on PHP 8.1, 7.x, or 5.x 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.

What to do before 14:00 UTC on October 21

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.

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 builds

Do 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. Pre-stage the patch so you can apply it in minutes. The goal is to remove every slow step before the clock starts. Refresh package metadata, confirm your mirrors or base images will have the new release, line up the maintenance approvals, and write the exact upgrade-and-reload commands per platform now. For PHP-FPM that means the package upgrade plus a systemctl reload php*-fpm; for mod_php it means a graceful Apache restart. Decide in advance who presses go at 14:00 UTC.

4. Make a plan for the systems that will not get a fix. For EOL PHP (8.1 and older, pending the official list), you cannot wait for an upstream patch. Options, roughly in order of preference: move to a supported branch today if the app will tolerate it; ask your hosting provider or distro whether they will backport; put the app behind strict network controls; or take it offline until you can do one of the above.

5. Consider the low-cost precaution, with eyes open. The widely circulated interim mitigation is to disable the upload-progress feature:

session.upload_progress.enabled = Off

in php.ini (or .user.ini / .htaccess where permitted), then reload PHP-FPM or the web server. Be precise about what this is: it is an unverified, community-suggested stopgap based on the speculated root cause. If that root cause is correct it may close one path; if there is a second path, or the root cause is something else, it will not save you. It is reasonable to apply anyway because the feature is rarely needed and turning it off costs almost nothing. It is not a substitute for patching.

6. Prepare your WAF rules, but do not trust them. 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 to stage. But memory-corruption RCEs are frequently reachable in ways that signature rules miss, and vendors will be writing rules blind until the details are public. Treat virtual patching as a speed bump, not the fix. Plan to deploy real vendor rules the moment they ship, and still patch.

7. Raise the floor on detection and recovery now. Snapshot or back up internet-facing PHP hosts before the storm 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.

What to do at release time and after

At 14:00 UTC on October 21, go to the source, not the rumor mill: php.net’s security announcements and the php-src GitHub security advisories will carry the official affected and fixed versions. Apply the real fixed release (ignore the version numbers floating around now), reload the runtime, and verify with php -v that every host actually moved.

Then 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/null

Review 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

Is this as bad as Log4Shell?

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 differences are that the fix is a straightforward runtime upgrade rather than a hunt through transitive dependencies, and that the exploit leaked before the patch, which compresses the defender timeline rather than widening it.

Which PHP versions are affected?

Officially unconfirmed as of October 20, 2026. Reporting ranges from PHP 8 only to PHP 5.4.0 and later. Check php.net’s official advisory after 14:00 UTC on October 21 for the authoritative affected and fixed-version list, and do not assume immunity before then.

Is there a public exploit?

A proof-of-concept tool called PHP2Shell has leaked, and at least one firm says it reproduced one of the two bugs. Expect fully public, reliable exploits at or shortly after the patch, because the patch itself reveals the bug. Do not download exploit bundles from unofficial pages.

Can a WAF protect me instead of patching?

Treat a WAF as temporary mitigation only. It may block some attempts and buy a few hours, but memory-corruption bugs are hard to filter reliably and vendor rules will lag the disclosure. Patch the runtime.

I am on an end-of-life PHP version. What should I do?

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 past the release.

Is it being actively exploited yet?

No confirmed in-the-wild exploitation had been reported as of October 20, 2026, but a weaponized proof-of-concept is circulating and mass exploitation is expected within minutes of the release. Prepare as if it starts the moment the patch lands.

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: Scheduled PHP security release with the official patches and version details.

The honest bottom line

The confirmed facts are enough to act on: two unauthenticated, critical RCEs in PHP core, a hard patch time of October 21 at 14:00 UTC, and a leaked exploit that makes the patch gap the whole ballgame. The unconfirmed parts (the exact version range and the precise root cause) are exactly the parts you should not guess at. Inventory your PHP now, isolate what is exposed, pre-stage the upgrade so you can patch in minutes, and have a separate plan for the end-of-life systems that will never get a fix. We will update this post with the official affected and fixed versions as soon as the release is published.

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.