PHP2Shell: Two Critical PHP Flaws (CVE-2026-109618, CVE-2026-109619) Give Attackers a Shell on Every Unpatched Site

If your website runs on PHP, and roughly three quarters of the web does, an unauthenticated attacker can now run code on your server with one crafted HTTP request unless PHP itself was patched on or after 21 October 2026. This isn't a WordPress bug, a plugin bug or a theme bug. It's two memory-corruption flaws in the PHP interpreter, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, each rated CVSS v4.0 9.2 (Critical). The PHP project calls updating "the only safe choice", the CVE identifiers leaked on a forum before the fix shipped, and Cloudflare was already reporting attack attempts on the morning of release. Some European hosts switched PHP off entirely rather than wait.

Do this in the next 10 minutes

1. Find out what PHP version actually serves your site. In WordPress: Tools → Site Health → Info → Server. On a server: php-fpm -v or php -v. Anything below 8.5.12, 8.4.27, 8.3.36 or 8.2.35 is vulnerable unless your host or distribution has backported the fix.
2. Work out who patches it. Managed WordPress and shared hosting: your host does, so check their status page and email. VPS, dedicated or anything you installed yourself: nobody but you. That group needs to act today.
3. Self-managed? Install the fixed packages and restart every PHP worker. A package upgrade without a restart of php-fpm or Apache leaves the old vulnerable code running in memory.
4. Can't patch today? Apply the interim settings below at server level and restart. They narrow the attack surface. They do not close it.
5. Behind Cloudflare? The managed WAF rules for these CVEs are on for every plan, including free. On Pro, Business and Enterprise, make sure they're set to block, not log. Treat it as a seatbelt, not a fix: anyone who finds your origin IP bypasses it.

Those five steps are the critical 80%. The rest of this article explains what the bugs do, why "keep WordPress updated" doesn't help this time, what the hosting industry is doing, and how to tell if someone has already been through.

What is PHP2Shell?

PHP2Shell is the community name for a pair of vulnerabilities in PHP's request-handling core, disclosed by the PHP project in its 21 October 2026 security release. Both allow unauthenticated remote code execution with the privileges of the web worker, which on most hosting is enough to read your database credentials, plant a web shell, and pivot to every other site on the same server.

• CVE-2026-109618, "RCE via OOM corruption". When PHP runs out of memory part-way through setting up a request, cleanup code runs against half-initialised internal data and treats garbage as valid. A crafted multipart request can trigger the out-of-memory condition while appearing to stay within configured size limits.
• CVE-2026-109619, "RCE via stale global state". Internal state that belongs to one request can survive after its memory has been freed. The next request handled by the same worker can use that stale pointer before normal initialisation resets it. In plain terms, a use-after-free that crosses request boundaries.
• CVSS: 9.2 (Critical) for both, vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H. A leaked pre-release post claimed 10.0. The official figure is 9.2.
• Authentication required: none.
• Affected deployments: every PHP installation that serves web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php as the highest risk, because the demonstrated exploit fires before any application code runs.
• Exploitation status: a working exploit was developed during the research. Cloudflare reported early attack attempts on the morning of 21 October. Public exploit code was expected within days.

Affected and patched versions

PHP branch	Vulnerable	Fixed in	Action
8.5	Below 8.5.12	8.5.12	Update and restart every worker
8.4	Below 8.4.27	8.4.27	Update and restart every worker
8.3	Below 8.3.36	8.3.36	Update and restart every worker
8.2	Below 8.2.35	8.2.35	Update now. 8.2 reaches end of life on 31 December 2026, so plan the move to 8.3 or 8.4 as well
8.1, 8.0, 7.4	All versions	No upstream release	The PHP security team published minimal source backports for people building from source. Distributions and LTS vendors received patches in advance. Ask your host or distro, then plan an upgrade
7.3 and older	All versions	None	Migrate, or take the site offline until you can

One trap worth knowing: Linux distributions often apply security fixes without changing the visible version number. Ubuntu's php8.3-fpm can show 8.3.6 in php -v and still contain the fix. Check the package changelog (apt changelog php8.3-fpm) or ask your host whether the 21 October release has been applied, rather than trusting the number alone.

How the two bugs work

CVE-2026-109618: memory runs out mid-request

PHP has to parse a request before your code sees it: headers, cookies, query string, and for a multipart/form-data POST, every part of the body. Each of those steps allocates memory. If an allocation fails, PHP abandons the request. The flaw is that it then runs its normal request-cleanup routine against internal structures that were only partly built, and cleanup trusts what it finds.

An attacker builds a multipart body that drives memory usage past the limit while the request still looks acceptable to the size checks, so the failure lands exactly where it's useful. Any application operation that allocates memory in proportion to attacker input (think image resizing, big JSON decodes) can trigger the same condition later in the request. On Apache mod_php this works before application code runs, which is why PHP calls it the highest-risk configuration. PHP-FPM terminates a worker if startup fails, which blocks that particular sequence, although the advisory notes FPM is likely susceptible after a successful startup and simply has no complete public exploit yet.

CVE-2026-109619: one request poisons the next

PHP workers are long-lived processes that handle thousands of requests in sequence. At the end of each one, PHP is supposed to clear every piece of per-request state. If a request dies abnormally, through a fatal error, memory exhaustion or an execution timeout, parts of that cleanup are skipped. A pointer to memory that has already been freed survives inside the worker. The next request to land on that worker can touch it before initialisation resets it, and reading or writing freed memory is the classic recipe for code execution.

Two paths are confirmed. The first goes through session upload progress, a feature that tracks file-upload status in the session and is enabled by default. It can consume stale state without the application ever calling session_start(), which is why WordPress sites are exposed even though WordPress doesn't use the feature. The second is PHP 8.5 only: the new fatal error backtrace feature, on by default, repopulates error state after it was meant to be reset. Both paths work against PHP-FPM as well as mod_php. Running several workers and recycling them reduces the odds per request. It doesn't remove the condition.

Why "keep WordPress updated" doesn't help this time

Most WordPress security advice assumes the bug lives in something you install: a plugin, a theme, core. Update it, done. These flaws live in the interpreter that runs all of that. WordPress.org has said plainly that no WordPress update is required or planned, because there's nothing WordPress can change. The same is true for Laravel, Drupal, Magento, Joomla, Symfony and every bespoke PHP application. A fully patched WordPress 6.9 on PHP 8.3.35 is vulnerable. A five-year-old WordPress on PHP 8.3.36 is not, at least to this.

That inversion matters for who's responsible. Plugin updates are a site-owner job. The PHP binary is a server job, and on shared or managed hosting it's a job you can't do yourself.

What to do, by hosting type

Managed WordPress hosting (Kinsta, WP Engine, Pressable, Flywheel, WordPress VIP)

The host patches PHP. Your job is to confirm it happened. Check the status page, check your inbox, and if you've heard nothing by the end of the day, open a ticket and ask the direct question: "Has the 21 October PHP security release been applied to my site's PHP version?" Several hosts put CDN or WAF rules in front of sites while the rollout completes. That's a sensible stopgap, not the fix.

Shared hosting (cPanel, Plesk and similar)

The host patches server-wide, usually via a cPanel or Plesk update plus a system update. cPanel has released fixed PHP packages including, unusually, backports for 8.1, 8.0 and 7.4. Plesk shipped fixed 8.2 to 8.5 with 8.0 and 8.1 in development. If your account is on PHP 8.1 or older, use the control panel's PHP selector to move to 8.2 or newer now rather than waiting for a backport that may never come. Back up first, and check your checkout, contact forms and login afterwards.

VPS, dedicated, or anything you set up yourself (DigitalOcean, Hetzner, Linode, AWS, Forge, Ploi, RunCloud)

Nobody patches this but you. On Ubuntu or Debian with the distribution packages or the sury.org repository:

sudo apt update
sudo apt install --only-upgrade 'php8.3-*'     # match your branch
sudo systemctl restart php8.3-fpm               # or: sudo systemctl restart apache2
php-fpm8.3 -v

On RHEL, Rocky, Alma and Fedora the Remi repository said it would have no updates on 21 October, so check dnf for the distribution's own backport and apply the interim settings in the meantime. Laravel Forge customers update PHP themselves from the server panel. Laravel Cloud, SpinupWP and similar platforms patch automatically, but confirm.

Whatever the route, restart every worker. PHP-FPM reloads are not enough if the master process keeps old workers alive, and Apache needs a full restart for mod_php. Then confirm with php -i | grep -i session.upload_progress that the running configuration is what you expect.

If you can't update today: interim settings

PHP's own guidance is blunt: these measures "reduce exposure to specific attack paths but do not make an installation safe." Apply them at server level, in php.ini, an FPM pool or the Apache configuration, so applications can't override them. Setting them with ini_set() or an FPM .user.ini is too late in the request to help.

; Blocks the confirmed session paths for CVE-2026-109619
session.upload_progress.enabled = 0

; PHP 8.5 only: blocks the confirmed backtrace path for CVE-2026-109619
fatal_error_backtraces = 0

; Narrows CVE-2026-109618 by removing the allocation failure PHP depends on.
; Use php_admin_value in the FPM pool so nothing can put a finite limit back.
memory_limit = -1

; Keep request bodies small. 8M if the app doesn't take uploads, 32M if it does.
post_max_size = 8M
upload_max_filesize = 2M   ; must stay below post_max_size

Then restart every worker. Three warnings from the advisory are worth repeating:

• Do not replace memory_limit with RLIMIT_AS or RLIMIT_DATA. Those cause exactly the allocation failure the bug needs. Container and cgroup memory limits are incomplete for the same reason, and can kill the FPM master along with every worker.
• Suppressing errors does nothing. Turning off display_errors, lowering error_reporting or sprinkling @ doesn't prevent stale-state access. If your application has an attacker-reachable fatal error or timeout, fix it.
• Block multipart at the edge if you don't need it. If an endpoint never accepts file uploads, have nginx, Apache or your WAF reject multipart/form-data before PHP parses it, and cap decoded body size, part count and header count for the ones that do.

How the hosting industry responded

By the evening of 21 October, Kinsta, Pantheon, OVHcloud, Netcup, SpinupWP, Register.it and Pressable had either completed or declared protection. WP Engine, Flywheel and DreamHost were rolling fixes behind CDN or firewall rules. Cloudways, Namecheap and Liquid Web had interim protections with final patches pending. Uberspace switched PHP off entirely for a period and Netcup took web hosting offline to patch. CloudLinux's Imunify360 was blocking the public exploit on Apache but only logging it on LiteSpeed, which left a lot of cPanel shared hosts in a worse position than their dashboards suggested. GoDaddy published an advisory telling customers to check versions without saying what GoDaddy itself would patch.

The pattern to notice: the better hosts told customers what they'd done and when. If yours hasn't, that silence is information.

Signs you may already have been hit

Exploitation leaves a server-side footprint, unlike the credential-leak bugs we've covered before. Look for:

• Unexpected child processes spawned by php-fpm, apache2 or httpd workers, especially shells, curl, wget, python or perl.
• New or modified files in the web root since 20 October, particularly PHP files with random names, files in wp-content/uploads that aren't media, or changes to wp-config.php, .htaccess and index.php.
• Segfaults in the PHP-FPM or Apache error log that line up with multipart POSTs in the access log. Failed exploit attempts often crash the worker before they succeed.
• Outbound connections from the web server to addresses you don't recognise.
• Bursts of multipart POSTs to pages that have no upload form, from a handful of IPs.

Rapid7 makes a point we'd underline: the absence of log entries does not prove an installation is safe. If a server ran vulnerable PHP with mod_php on the public internet after the CVE IDs leaked, treat "we didn't see anything" as "we didn't look hard enough" and run a file-integrity check against a known-good copy.

Why this one is different

Most critical web vulnerabilities are scoped: one plugin, one product, one vendor. This is the first interpreter-level, unauthenticated RCE in PHP in years, it affects every framework and CMS at once, and roughly 59% of the versioned PHP hosts visible on Shodan were running a branch that gets no upstream fix. That's close to 900,000 servers whose only routes to safety are a vendor backport, a major-version upgrade, or going offline. Many of them belong to small businesses who don't know what PHP is, let alone which version they're on.

For a managed site, an advisory like this is a ticket opened at 09:00 on disclosure day: PHP version confirmed, host's patch status chased, interim settings applied where the host is slow, file integrity verified once the patch lands. For an unmanaged site, it's a vulnerable interpreter running for months until something crawls through it. If you're not sure which camp you're in, our free audit will tell you what PHP version your site actually runs and who's responsible for it.

Frequently asked questions

I'm on PHP 8.1. Am I stuck?

Not necessarily. cPanel has shipped fixed 8.1, 8.0 and 7.4 packages, Pantheon and OVHcloud are patching old branches through LTS vendors, and the PHP security team published source backports. But none of that is guaranteed for your host or distribution. Ask, and if the answer is vague, move to 8.2 or newer. 8.1 has been out of security support for almost a year; this is the push.

Does Cloudflare protect me?

Partly. Cloudflare's WAF rules for these CVEs are enabled on every plan, including free. But WAF rules match known exploit patterns, attackers will vary the payload, and anyone who discovers your origin IP talks to your server directly. Use it as defence in depth while you patch, not instead of patching.

My site is behind a login. Does that help?

No. The exploit happens during request parsing, before PHP has any idea whether the visitor is logged in. "PR:N" in the CVSS vector means no privileges required, and for mod_php the attack completes before WordPress loads.

Is WordPress going to release an update?

No. WordPress.org has said no update is required or planned, because the bug isn't in WordPress. The same goes for every other PHP application.

Is this being exploited in the wild?

Cloudflare reported attack attempts on the morning of 21 October, before the fix was public, which is consistent with the CVE IDs having leaked days earlier. Rapid7 had not confirmed in-the-wild compromise at publication but expected a public exploit "soon". Plan on the assumption that mass scanning is already underway.

Does Obsyde's own platform run PHP?

No. obsyde.com runs on Next.js and FastAPI, with no PHP on the host, in any container, or in any image. Our nginx drops every request for a .php path before it reaches an application. Our WordPress plugin, Obsyde Aegis, is PHP, but it executes on your hosting and is only as safe as the PHP underneath it, which is exactly why we wrote this.

Sources and references

• PHP.net — 21 October 2026 security release announcement
• Rapid7 — CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated RCE in PHP
• Codeable — PHP Security Release on 21 October 2026: What WordPress Site Owners Need to Do
• Infosecurity Magazine — Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patch
• Google Cloud — Responding to core PHP vulnerabilities
• Phoenix Security — PHP Core RCE exposure analysis