PHP2Shell (CVE-2026-109618 and CVE-2026-109619): Who Is Affected and How Businesses Are Fixing It

On October 21, 2026, the PHP project released emergency updates for two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, now widely called “PHP2Shell.” Any internet-facing website or app running an unpatched PHP runtime is at risk. The complete fix is upgrading PHP itself to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a vendor package with the fix backported) and restarting PHP workers. Updating WordPress, plugins or themes does not fix it.

PHP powers a large share of the public web: WordPress and WooCommerce sites, Drupal and Joomla installs, Magento storefronts, Laravel apps, client portals, hosting control panels and plenty of quietly forgotten internal tools. That reach is exactly why this disclosure has security teams, hosting providers and MSPs working through the weekend.

This report covers what the flaws are, how the disclosure unfolded, who is exposed, and the specific steps organizations are taking right now to close the gap.

What Are CVE-2026-109618 and CVE-2026-109619?

Both vulnerabilities live in the PHP interpreter’s core request handling, not in any particular application. The PHP security team rates each one 9.2 (Critical) on CVSS v4.0, and its advisory states they can be exploited without authentication.

CVE-2026-109618: the out-of-memory flaw. When PHP hits an out-of-memory condition while processing a request, it can stop processing while internal request structures are only partially initialized. Specially crafted multipart requests (the same request type used for file uploads and form posts) can reach this code path and corrupt memory.

CVE-2026-109619: the stale-state flaw. This is a use-after-free bug in PHP’s request state management. Request-owned state is not always reset before its underlying memory is released, so a later request handled by the same worker process can encounter that stale state before PHP’s normal initialization replaces it.

Chained or individually, the result is the same worst case: an attacker on the internet sends crafted traffic to a PHP-served site and gets code execution inside the PHP process. From there, typical follow-on activity includes web shells, credential theft from configuration files, database access and lateral movement.

How Did the Disclosure Unfold?

The flaws were found through a coordinated research process, but details leaked two days before the planned disclosure date, which compressed the patch window for everyone.

Date (UTC)	What happened
August 19, 2026	Wiz Research identifies the first bug (Wiz reports AI models helped find and chain the flaws)
August 24, 2026	Issue reported to the PHP project
September 21, 2026	PHP acknowledges the report
October 20, 2026	Details leak ahead of coordinated disclosure; watchTowr confirms the flaws are real; PHP publishes an advance notice of a security release; CERT-EU issues Security Advisory 2026-018
October 21, 2026, 14:00	PHP ships fixed releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35
October 22, 2026	Original coordinated disclosure date

Is PHP2Shell Being Exploited Right Now?

Treat it as exploited. Reporting is still settling, but the direction is clear:

As of October 21, PHP itself had not confirmed in-the-wild exploitation, and CISA had not yet added either CVE to its Known Exploited Vulnerabilities (KEV) catalog.
Security vendors including Aikido and Patchstack report active exploitation, and Cloudflare has reported exploit activity.
Wiz and Datadog have both demonstrated working exploitation in research settings. A public proof-of-concept is also circulating; SANS describes it as unreliable, but it gives attackers a starting template.
Underground forum activity shows criminals actively seeking a working exploit.

For Apache with mod_php in particular, PHP documents a demonstrated unauthenticated exploit that works with a single request and fires before any application code runs. That means no login page, no vulnerable plugin and no user interaction are needed.

Who Is Affected?

The short answer: anyone serving web requests through an unpatched PHP runtime. Because the bug is in the interpreter, the application on top does not matter.

Affected server configurations

Apache with mod_php (highest risk, single-request exploit documented)
PHP-FPM (behind Nginx, Apache or a load balancer)
php-cgi
FrankenPHP
LiteSpeed

Affected PHP versions

All PHP versions prior to the fixed releases, back to at least PHP 5
Fixed releases exist for the supported 8.2, 8.3, 8.4 and 8.5 branches
Source-level backports have been published for 8.1, 8.0 and 7.4
PHP 7.3 and older have no fix at all

Scale of exposure

Shodan lists roughly 884,000 internet-facing hosts running PHP 8.1 or older, plus about 740,000 more running PHP without a visible version number. That is before counting every current-version server that simply hasn’t been updated yet.

Where PHP hides in a typical small or mid-sized business

The public website (very often WordPress or WooCommerce)
Client or patient portals, booking systems and payment pages built on PHP frameworks
Hosting control panels such as cPanel or Plesk
Network appliances, NAS devices and security products with embedded web interfaces
Windows software that bundles its own PHP runtime (local dev stacks, some line-of-business tools)
Container images that pin an older PHP base image
Abandoned microsites, staging sites and old marketing landing pages nobody remembers launching

That last group is where most real-world compromises will come from. A server nobody owns is a server nobody patches.

What About Managed Hosting and WordPress.com?

If your site runs on a fully managed platform (WordPress.com, WP Engine, Kinsta and similar), the host patches the PHP runtime for you. Most major managed hosts moved quickly. It is still worth confirming with your provider’s status page or support team that the fix is applied, rather than assuming.

If you are on shared hosting, a VPS or your own servers, you or your IT provider own the runtime, and this needs action now.

Why Doesn’t “apt upgrade” Always Prove You Are Safe?

This is the most common point of confusion right now. Two reasons:

Backported fixes don’t change version numbers. Linux distributions such as Ubuntu, Debian and RHEL often backport security patches into their existing packages without bumping to the upstream PHP version. Your server might show 8.1.x and still be patched, or show a newer number and still be vulnerable if the package hasn’t landed. Check your distribution’s security advisory for the specific package version that contains the fix.
The PHP you check may not be the PHP serving traffic. Running php -v in a terminal reports the command-line binary. The runtime actually serving web requests (PHP-FPM, mod_php, a container) can be a different installation entirely. Verify the web-serving runtime directly.

What Fixes Are Businesses Implementing?

Here is the sequence security teams and MSPs are following this week, in priority order.

1. Build a full PHP inventory

Start with everything internet-facing, then work inward. Include the hidden categories above: appliances, hosting panels, bundled Windows software and container base images. External scanning tools and the free SOCRadar PHP2Shell Checker can help flag exposed versions, but an inconclusive result does not prove a site is safe.

2. Patch the runtime, starting with mod_php

Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution’s or vendor’s fixed package. Prioritize Apache mod_php servers first given the single-request exploit path. Then:

Restart PHP-FPM pools or the web server so no worker keeps running old code
Rebuild and redeploy containers from patched base images (patching a running container is not enough)
Confirm the fixed version on the web-serving runtime itself

3. Restrict anything you cannot patch today

If a system can’t be patched immediately, take it off the public internet. Organizations are putting unpatched systems behind VPN, IP allowlists or zero trust network access (ZTNA), or temporarily taking non-essential sites offline. Sophos and others recommend exactly this as an interim step.

4. Apply temporary hardening (as a bridge, not a fix)

PHP’s advisory lists mitigations for organizations that cannot upgrade yet, while stressing that updating is the only complete solution:

For CVE-2026-109619: set session.upload_progress.enabled = Off (it is On by default) and restart PHP workers
For CVE-2026-109618: reduce post_max_size, keep upload_max_filesize below it, and enforce request-size limits at the web server and any reverse proxy
Set expose_php = Off so your PHP version isn’t advertised in response headers
Enable vendor WAF rules where available (Cloudflare and other providers have shipped detections)

None of these close the vulnerability on their own. They reduce exposure while patching completes.

5. Hunt for signs of compromise

Because exploitation grants code execution inside the PHP process, patching does not undo anything that already happened. Review logs and systems for:

Multipart POST requests followed by memory-limit errors
Bursts of HTTP 500 responses
Oversized or malformed PHPSESSID cookies
New or modified files in the web root, especially unfamiliar .php files (web shells)
New cron jobs, new user accounts or new SSH keys
PHP worker processes spawning shells or download tools such as curl or wget

If anything turns up, treat the server as compromised: isolate it, rotate every credential stored on it (database passwords, API keys, SMTP credentials, cloud keys) and rebuild from a known-good state.

6. Plan the end-of-life cleanup

PHP 7.3 and older will never receive a fix. Any site still on those versions needs a migration plan, not a workaround. This is a good moment to retire abandoned sites entirely rather than patching them.

Action Checklist

List every internet-facing system that runs PHP, including appliances, panels and containers.
Confirm with managed hosts that their PHP runtime is patched.
Upgrade self-managed runtimes to 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a verified backported package, mod_php servers first.
Restart PHP workers and redeploy containers; verify the web-serving runtime version.
Move anything unpatched behind VPN, allowlists or ZTNA.
Apply interim settings (session.upload_progress.enabled = Off, tighter request size limits) where patching is delayed.
Hunt logs and file systems for web shells and suspicious PHP worker activity.
Rotate secrets on any server showing signs of compromise.
Schedule migrations off PHP 7.3 and older, and decommission abandoned sites.

Frequently Asked Questions

Does updating WordPress or my plugins fix PHP2Shell? No. The vulnerability is in the PHP interpreter, not in WordPress or any plugin. Keeping WordPress current is still good practice, but only a patched PHP runtime closes these two CVEs.

My site is on WordPress.com or another managed host. Do I need to do anything? Managed platforms patch the runtime on your behalf. Check your provider’s status page or ask support to confirm, then focus your attention on anything you host yourself.

Is disabling session upload progress enough? No. Setting session.upload_progress.enabled = Off is a partial mitigation for CVE-2026-109619 only. It buys time; it does not replace patching.

We run PHP 7.4 or 8.1. Are we stuck? Source-level backports exist for 8.1, 8.0 and 7.4, and your Linux distribution may ship a patched package. Long term, those branches are out of support and should be upgraded. PHP 7.3 and older have no fix.

How do we know if we were already compromised? Look for unfamiliar PHP files in the web root, new scheduled tasks or accounts, PHP processes launching shells or download utilities, and multipart requests paired with memory errors in your logs. If you find any of these, isolate the system and rotate credentials before rebuilding.

Need a Second Set of Eyes on Your Exposure?

Websites, portals and line-of-business tools often sit outside the Microsoft 365 environment that most IT attention goes to, which makes them easy to miss in a fast-moving event like this. Calibrate 365 can help you inventory internet-facing systems, verify that patches actually landed on the runtime serving traffic, and review logs for signs of compromise. For MSP partners, we can support the same review across your client base under your brand.

Calibrate 365 Tenant Group | info@calibrate365.com | 603-759-8721 | calibrate365.com

This post is provided for informational purposes based on publicly available vendor advisories and security research as of October 2026. Exploitation status and patch availability are evolving; consult the PHP project’s security advisories and your operating system or hosting provider’s guidance for your environment’s current status.