PHP2Shell (CVE-2026-109618 / CVE-2026-109619): am I affected, and how do I patch?

On 21 October 2026, at 14:00 UTC, the PHP project shipped four emergency releases at once: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two bugs in the PHP engine, CVE-2026-109618 and CVE-2026-109619, that together are being called PHP2Shell. Both are rated 9.2 (Critical) on CVSS v4.0, both can be triggered by an unauthenticated web request, and both end in code running on the server as the PHP worker user. PHP's own wording is the shortest summary you will find: "There are no complete mitigations, updating is the only safe choice."

This post is for the people who actually have to deal with that sentence: anyone running a site on PHP, whether on a VPS they administer, a cPanel or Plesk box, or a shared plan where the host controls PHP. It covers what the two bugs are in plain language, which versions are affected and fixed, how to find out which PHP version really serves your site (the answer is not always php -v), how to update on each kind of hosting, why a composer update changes nothing here, and what to look at if a server was exposed for a few days. Last updated 22 October 2026 (UTC); there is a changelog at the end.

What happened, in five lines

• Two memory-safety bugs in PHP's request handling were fixed on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (php.net security advisory).
• They affect every PHP installation that serves web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php the highest risk, with "a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."
• The CVE IDs leaked on 20 October, so PHP pulled the release forward by a day, from 22 October to 21 October (PHP Foundation).
• Attack attempts were observed before and after the release: Amazon logged one against a honeypot on 17 October, Cloudflare and watchTowr reported attack traffic on 21 October. No confirmed breach had been published by 22 October.
• The fix for the first bug was delayed by about two years after its first signs surfaced in 2024, during work on findings from an external audit; the PHP Foundation calls that delay "a structural failure".

Screenshot: the security advisory on php.net, 21 October 2026.

The two bugs in plain language

CVE-2026-109618, "RCE via OOM corruption" (remote code execution via out-of-memory corruption, in PHP's title). When PHP runs out of memory in the middle of setting up a request, it jumps straight to error handling and leaves the half-built request data behind. The clean-up code that runs next treats that half-built data as if it were complete. An attacker who can make PHP run out of memory at the right moment, and the public write-ups describe several ways to do that with crafted multipart (file-upload style) requests, can turn that confusion into code execution. PHP's advisory describes it as "out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid."

CVE-2026-109619, "RCE via stale global state". PHP keeps some internal pointers that refer to memory belonging to the current request. In certain paths those pointers survived after the memory was freed, so the next request handled by the same worker process could pick them up before PHP reset them. PHP's GitHub advisory for it (GHSA-6wmf-4rv5-p3rp) names two confirmed paths that use the stale state before PHP resets it, one through INI diagnostics (warnings or notices emitted while a request is still being set up) and one through the session upload-progress feature, and lists the outcomes as "unauthenticated heap use-after-free, memory disclosure and remote code execution".

Neither bug is in any application. A perfectly written WordPress plugin, Laravel app or custom script runs on top of the same engine, which is why the advisory scopes the risk to "all PHP installations serving web requests" rather than to any framework. The command-line version of PHP (the one php -v reports on) is not in that list.

Affected and fixed versions

Branch	Vulnerable	Fixed in	Status
PHP 8.5	8.5.0 – 8.5.11	8.5.12	supported
PHP 8.4	8.4.0 – 8.4.26	8.4.27	supported
PHP 8.3	8.3.0 – 8.3.35	8.3.36	supported
PHP 8.2	8.2.0 – 8.2.34	8.2.35	supported to 31 Dec 2026
PHP 8.1, 8.0, 7.4	all releases	source-only backport branches	end of life
PHP 7.3 and older	all releases	nothing from PHP	end of life

For 7.4, 8.0 and 8.1 the PHP project published minimal source-only backport branches on GitHub (PHP-8.1-CVE-2026-109618-109619, and the same for 8.0 and 7.4) "to help people building from source or without access to an LTS vendor". In practice that means: if you are on an old branch, the fix reaches you through your distribution, control panel or host, or not at all.

How many servers that is: VulnCheck counted 2,608,039 internet-facing hosts running PHP in the 30 days before 21 October and estimated 99.998% of them as vulnerable or likely vulnerable; 1.1 million-plus (about 42%) were on end-of-life branches (VulnCheck, 21 Oct 2026). You may also have seen "884K hosts get no fix" in coverage; that figure traces back to a single Shodan-based estimate quoted by one vendor, so this post uses VulnCheck's numbers.

Figure: most PHP hosts either hide their version or sit on a branch the PHP project no longer releases for. Data: VulnCheck Target Intelligence, 21 October 2026.

Step 1: find out which PHP actually serves your site

This is where most people get it wrong, in one of three ways.

php -v is the command-line binary, not necessarily the web one. A server can have PHP 8.3.36 on the command line and still serve web requests through an older PHP-FPM pool or mod_php module. Check the version from inside a web request: put a file containing <?php phpinfo(); in the web root for a minute, open it in a browser, read the PHP Version and Server API lines, then delete the file. On a VPS you can also run php-fpm8.3 -v (Debian/Ubuntu) or php-fpm -v (RHEL family) and apachectl -M | grep php to see which module Apache loads.

On managed hosting the version number may not change. Hosts and distributions often backport the fix into the version they already ship, so the number stays at, say, 8.3.35 while the vulnerable code is gone. Hostinger says exactly this about its platform: the fix "is built into the PHP version your site already runs", and the way to confirm it is the Build Date line in PHP Info, "October 21, 2026 or later means your site has the fix" (Hostinger, updated 22 Oct 2026). Ubuntu works the same way: the patched package on 24.04 is php8.3 8.3.6-0ubuntu0.24.04.13, which still reports 8.3.6 (USN-8948). On Debian and Ubuntu, apt changelog php8.3 | grep CVE-2026-109618 tells you whether the installed package carries the fix; on RHEL, Alma and Rocky, rpm -q --changelog php | grep CVE-2026-109618 does.

We did this check on the shared-hosting server that runs this site. The hPanel PHP Info page reports PHP 8.3.35, one number below the official fixed release, with a build date of 21 October 2026, which under Hostinger's rule means the backported fix is installed. The screenshot is the relevant part of that page.

Screenshot: PHP Info for ipcheckerpro.com's hosting account on 22 October 2026 (UTC). The version string did not change; the build date did.

Response headers are a hint, not an answer. Some servers send X-Powered-By: PHP/8.2.34. If yours does, you can read it with our HTTP headers tool and you have a quick answer; if it is missing, that proves nothing, because many hosts and frameworks remove the header. Do not rely on it, and consider turning it off (expose_php = Off) once you have patched, since it tells attackers exactly which branch to aim at.

Step 2a: patching on a VPS or dedicated server

Update the package, then restart the PHP worker processes, because a running PHP-FPM pool or Apache process keeps the old code in memory until it is restarted.

• Ubuntu 22.04 / 24.04 (distribution packages): sudo apt update && sudo apt upgrade, then sudo systemctl restart php8.3-fpm (or the version you run) and sudo systemctl restart apache2 if you use mod_php. Fixed builds: 8.3.6-0ubuntu0.24.04.13 on 24.04, 8.1.2-1ubuntu2.28 on 22.04 (USN-8948-1).
• Ubuntu/Debian with the ondrej/sury repositories: the same apt upgrade brings php8.4 8.4.27-1+… and php8.3 8.3.36-1+…, published on 21 October (launchpad.net/~ondrej/+archive/ubuntu/php).
• Debian 12 and 13: apt upgrade to php8.2 8.2.35-1~deb12u1 (DLA-4848-1) or php8.4 8.4.27-1~deb13u1 (DSA-6574-1) (Debian security tracker).
• RHEL, AlmaLinux, Rocky with the Remi repository: sudo dnf upgrade 'php*' then sudo systemctl restart php-fpm; php-8.4.27 and php-8.5.12 module builds are in rpms.remirepo.net.
• Docker: pull a tag that carries the fix (php:8.4.27-fpm, php:8.3.36-apache, and so on; the floating 8.4, 8.3 tags now resolve to them, Debian images pushed on 21 October, Alpine on 22 October per Docker Hub), rebuild your image and redeploy. Restarting the old container does nothing.
• Built from source: build the fixed release or, on 7.4/8.0/8.1, the backport branch linked above.

If you cannot update today, PHP lists partial measures that "reduce exposure to specific attack paths but do not make an installation safe": set session.upload_progress.enabled = 0 in php.ini or the pool config (not via ini_set() or .user.ini) and restart every worker; keep post_max_size small (PHP suggests 8M if the site takes no uploads, 32M if it does) with upload_max_filesize below it; on PHP 8.5 set fatal_error_backtraces = 0. These are stopgaps, and watchTowr goes further, calling INI-only mitigations ineffective. A web application firewall in front of the server is another layer: Cloudflare's managed rules for both CVEs have been on by default, including for free plans, since 03:02 UTC on 21 October (Cloudflare).

Step 2b: patching on cPanel, Plesk and shared hosting

cPanel / WHM. EasyApache 4 change log 25.91 (21 October) updates ea-php82 to 8.2.35, ea-php83 to 8.3.36, ea-php84 to 8.4.27 and ea-php85 to 8.5.12, and backports the fix to ea-php74, ea-php80 and ea-php81 (cPanel EA4 change log). The server administrator runs WHM » Software » System Update (or /scripts/upcp), then opens MultiPHP Manager to confirm which version each account uses, and restarts Apache and PHP-FPM. If you are a cPanel user rather than the server owner, you cannot install the update yourself; MultiPHP Manager only lets you pick among versions the administrator installed, so check PHP Info and ask them.

Plesk. Plesk published PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October and updated its own engine to 8.4.27 (Plesk change log); apply them from Tools & Settings » Updates.

Hostinger. Hostinger says it added firewall rules for the known exploit patterns, switched off session.upload_progress on its LiteSpeed, PHP Selector and cPanel PHP-FPM setups, started rejecting malformed upload requests, and completed the PHP rollout on all managed hosting servers (Web, Cloud and cPanel plans, every version from 5.2 to 8.5) at 06:44 UTC on 22 October, with customers emailed; VPS customers manage their own PHP and must update themselves (Hostinger, updated 22 Oct 2026). The hPanel path Websites » Dashboard » PHP Configuration only switches between branches (8.2–8.5); the patch level is Hostinger's, which is why the build-date check above matters.

Any other shared host. You cannot patch PHP on a shared plan; the host does. Check the build date or version, read the host's status page, and if there is nothing, ask support one precise question: "Which PHP build serves my account, and does it include the fix for CVE-2026-109618 and CVE-2026-109619?" If you are not sure who hosts a site you inherited, a WHOIS lookup on the domain and on its IP address usually names the provider. Cloudflare's advice for this situation is simply "Ask your hosting provider to apply the update if they manage PHP."

Why composer update did not fix it

Composer manages the libraries inside your project. PHP itself appears in Composer only as a platform package, a virtual entry that describes what is installed on the machine; the Composer documentation describes platform packages as "things that are installed on the system but are not actually installable by Composer" (Composer docs). Running composer update, updating WordPress, Laravel, Drupal or any plugin therefore leaves the vulnerable engine exactly where it was. Cloudflare put it plainly: "These flaws are in the PHP runtime, so updating website code or a plugin(s) alone does not fix these vulnerabilities."

The same logic applies to anything else that sits on top of PHP: a framework patch, a WAF plugin written in PHP, or a security scanner plugin cannot repair a bug that fires before, or underneath, their code.

If you are on PHP 7.4, 8.0 or 8.1

These branches are end of life, so there is no new 7.4, 8.0 or 8.1 release to install, and the PHP project's advisory is explicit that 8.1 and older "no longer receive updates from the PHP project". What exists instead:

• distribution packages that carry the backport (Ubuntu 22.04's php8.1, cPanel's ea-php74/80/81, CloudLinux's alt-php builds);
• the source-only backport branches on GitHub for people who compile PHP;
• extended-support vendors for 7.3 and older.

If none of those applies to your server, treat the migration to 8.2 or newer as the fix, not as a project for next quarter. PHP 8.2 itself leaves security support on 31 December 2026, so 8.3 or 8.4 is the sensible landing point.

Signs of exposure and what to do after patching

Patching stops new attacks; it does not undo a successful one. Amazon's threat intelligence team recommends starting any investigation from the earliest known exploitation attempt rather than from the public disclosure, which for them is 17 October 2026 (Amazon, 21 Oct 2026). What the people who have looked at real attack traffic suggest checking:

• Web server logs for unusual multipart POST requests, especially ones containing PHP_SESSION_UPLOAD_PROGRESS, and bursts of HTTP 500 responses or memory-limit errors around the same time (Amazon; Wiz).
• PHP error logs with log_errors on; PHP's GitHub advisory for the second bug recommends reviewing them, with the caveat that "absence of an error in logs is not proof of safety".
• The filesystem: new or recently modified .php files in the web root and upload directories, unexpected cron entries, and new accounts tied to PHP processes (watchTowr). Preserve logs and copies of suspicious files before cleaning up.
• Processes and network: unexpected child processes of the PHP worker and, as general practice rather than advisory guidance, outbound connections the site has no reason to make.
• Attack sources: Amazon published the addresses it saw, among them 103.216.220.92 on 17 October and 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 and 95.217.98.37 on 21 October, with the advice to investigate hits from them rather than simply block, because they are shared anonymisation infrastructure (a WHOIS or ASN lookup shows which network each address belongs to).

Two things worth doing regardless: run a port scan of your own server from the outside to make sure only the services you expect are reachable (a web shell often comes with an extra listener), and if the site is behind Cloudflare, read the blocked events under Security › Security Analytics, filtered by the rule IDs in Cloudflare's post.

How a 2024 audit finding became an emergency two years later

The PHP Foundation's post on release day is unusually candid. PHP's first external audit in years, in 2024, was carried out by Quarkslab through OSTIF with funding from Germany's Sovereign Tech Agency. While fixing one of the issues it reported, a Foundation-contracted core developer found "the first signs of the OOM problem", without a concrete exploit path. The fix then stalled: competing approaches with different trade-offs, a security team that worked by consensus and had little capacity. In the Foundation's words, "the delay was a structural failure, caused by both the security team's decision process and its lack of resources."

Then, in the summer of 2026, several teams found the same root cause independently: Calif began an audit on 30 July (as part of OpenAI's "Patch the Planet" effort) and reported unconditional remote code execution on 11 August, as did OpenAI the same day; Wiz reported on 24 August; OpenAI sent further attack vectors on 18 September. The release was scheduled for 22 October. Around 15:00 UTC on 20 October the CVE IDs, a wrong score (10.0) and a wrong release time appeared in a Hacker News post and spread on social media; a proof-of-concept video was also published by mistake. PHP posted an advance notice at 19:30 UTC and brought the release forward to 21 October at 14:00 UTC. The person behind the Hacker News post apologised two days later, saying he had been told there was no embargo.

The Foundation says it is changing how security decisions are made (majority rather than consensus, with leadership pulled in earlier when a serious fix stalls), had already created an Ecosystem Security Team in May 2026 with two engineers since, and is asking companies, hosts, distributions and governments to fund security work. Whatever you think of a two-year gap, the way PHP handled the final week, pre-announcing, releasing early and publishing backport branches for unsupported versions, is the part worth copying.

What is still unclear (as of 22 October 2026, UTC)

• Whether any real-world compromise has happened. Several vendors report attempts, with attackers changing their payloads to get past filters, and Amazon says the bugs are "broadly exploited in the wild"; none has published a confirmed breach. Expect that to change.
• How exactly the second bug (CVE-2026-109619) was found; the Foundation attributes the 2024 finding only to the out-of-memory problem.
• Which hosts have finished rolling the fix out. Hostinger, cPanel, Plesk, Ubuntu, Debian, Remi, Docker and AWS have published dates; if yours has not, ask.

Changelog

• 22 Oct 2026 — First published.