Quick answer: PHP2Shell is two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2. An attacker who is not logged in can use them to run code on the server, and the demonstrated exploit fires before any WordPress code runs. The fixes are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on October 21, 2026. No WordPress or plugin update is involved. Check your PHP version under Tools → Site Health → Info → Server and make sure your host has applied the fix.
Most posts on this blog are about a plugin. This one is about the thing every plugin, every theme and WordPress itself runs on. When PHP is broken, it doesn't matter how tidy the site on top of it is: a security plugin, two-factor authentication and a perfect update record all live inside WordPress, and this attack gets in before WordPress starts.
What is PHP2Shell?
PHP is the language WordPress is written in. Every time someone visits a WordPress page, the server starts a PHP worker that reads the request, sets up memory for it, runs WordPress and cleans up afterwards. Both flaws sit in that setup and cleanup, not in any application.
| CVE-2026-109618 | CVE-2026-109619 | |
|---|---|---|
| What goes wrong | If memory runs out while PHP is still setting up a request, the cleanup afterwards treats half-built data as valid | State from one request survives after its memory is freed, and the next request on the same worker can use it |
| Severity | CVSS 9.2, Critical | CVSS 9.2, Critical |
| Login needed | No | No |
| Worst case | Code running on your server with the web server's permissions | The same, plus confirmed memory disclosure: data from other requests leaking out |
PHP says every installation that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates Apache with mod_php highest, because there a single unauthenticated request can trigger the attack before any application code runs. The oldest vulnerable code researchers found dates back to PHP 5.4, released in 2012.
The research is credited to Calif, Wiz and OpenAI, among others, and both Calif and Wiz said they used AI models to do it. After the release, Wiz demonstrated unauthenticated code execution against WordPress, Drupal and Joomla, and a separate memory disclosure path that can expose passwords, tokens, API keys and certificates.
What happened, and when?
| When (UTC) | What happened |
|---|---|
| Oct 20 | The CVE numbers leak in a Hacker News post. It is taken down, but screenshots spread |
| Oct 20 | PHP's security team gives advance notice: a security release on Wednesday, October 21, 14:00 UTC, fixing two critical vulnerabilities, both rated CVSSv4 9.2. It was originally planned for October 22 and moved up a day because of the leak. CERT-EU issues advisory 2026-018 |
| Oct 21, 14:00 | PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 released, with source backports for 7.4, 8.0 and 8.1. Linux distributions had the patches in advance |
| Oct 21 | Calif and Wiz publish technical details. Cloudflare says it is "seeing early attacks emerging" and deploys firewall rules for every customer, free plans included. watchTowr reports exploitation attempts against both flaws |
Not everyone sees the same picture yet. The PHP team says the proof-of-concept code circulating after the leak did not work when it checked, and Huntress had seen no exploitation across its customers by the evening of October 21. But the details are public now, and the last core flaw we covered went from patch to attack in a day. The leaked numbers also carried a CVSS of 10.0; PHP says that was wrong, and 9.2 is the official rating.
Which PHP versions are fixed?
| Your PHP branch | Fixed in | Status |
|---|---|---|
| 8.5 | 8.5.12 | Official release |
| 8.4 | 8.4.27 | Official release |
| 8.3 | 8.3.36 | Official release |
| 8.2 | 8.2.35 | Official release |
| 7.4, 8.0, 8.1 | No release | End of life. PHP published source patches for people who build PHP themselves; otherwise it depends on your distribution or an LTS vendor |
| 5.4 to 7.3 | Never | End of life, no fix from PHP |
One catch: hosts that install PHP from their Linux distribution often get a patched build that keeps the old version number. If Site Health shows something below the numbers above, it does not automatically mean you are exposed. Ask your host whether the October 21 fix is applied.
Do I need to do anything on WordPress?
WordPress.org says no WordPress update is required or planned. The fix is PHP, so who does the work depends on how your site is hosted.
- Managed WordPress hosting: your host patches PHP. As of the afternoon of October 21, Pressable, SpinupWP and Plesk reported fixes in place; SiteGround, WP Engine, Flywheel, DreamHost, Kinsta and OVHcloud reported protection at the server or network level with patches rolling out; Pantheon, Liquid Web, Rocket.net, Cloudways and Namecheap were patching; cPanel-based hosts and CloudLinux were waiting for upstream packages. Netcup and Uberspace switched hosting or PHP off as a precaution.
- Shared hosting with a PHP version picker: your host still patches the builds, but if you are on 8.1 or older, you are on a branch with no official fix. Move to 8.2 or later.
- Your own server or VPS: you patch it. Install the fixed packages, then restart every PHP worker: a patched binary on disk does nothing until the old workers are gone. GoDaddy and Laravel Forge both ask customers to check or update PHP themselves.
What should I do today?
- Check your version. Tools → Site Health → Info → Server. Note the PHP version and whether the host or you manages it.
- Get a yes from your host. On managed or shared hosting, ask: "Is the October 21 PHP security fix applied to my site?" A version number alone may not answer it.
- If you run the server, update and restart PHP now. Check that your package source actually has the update; some third-party repositories lagged behind on release day.
- If you are on PHP 8.1 or older, plan the upgrade this week. Take a full backup, test the site on 8.2 or later on staging, then switch. Old plugins are the usual reason a site is stuck on old PHP; this is the week to find out which ones.
- If you can't update yet, narrow the gap. PHP lists interim settings:
session.upload_progress.enabled=0(WordPress doesn't use upload progress), plusfatal_error_backtraces=0on 8.5, and a fixed memory limit that applications cannot override. Restart PHP after changing them. If the site is behind Cloudflare, its managed rules help too. None of this is a fix. - After patching, look for anything that got in first. New PHP files in the web root or uploads, administrators you don't recognise, new cron jobs. If you find any, here is what to do in the first hour after a hack, and rotate every secret the site could reach, because of the memory disclosure path.
Why does a PHP flaw matter more than a plugin flaw?
A plugin flaw only hits sites that run that plugin, and a security plugin or firewall can often block it. PHP2Shell hits every site on a vulnerable PHP build, whatever plugins it runs, and it is triggered before WordPress or any security plugin has loaded. A WordPress site cannot defend itself against it. Only the layer underneath can be fixed.
That is the part of running WordPress that rarely shows up on the invoice: the site is never just the site. It is the site plus the PHP version under it, plus whoever keeps that version patched, plus a plan for the day the branch you are on goes end of life. A site that is built ahead of time and served as plain files has no PHP running when a visitor arrives, so a flaw like this one has nothing to reach. If you are weighing that trade, this is what leaving costs and what you would move to.
This was not a quiet week otherwise: the same days brought stolen UpdraftCentral keys being used to install backdoors and a poisoned Rank Math PRO update.
FAQ
What is PHP2Shell?
PHP2Shell is the name used for two critical vulnerabilities in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619, fixed on October 21, 2026. Together they allow an unauthenticated attacker to run code on a web server running a vulnerable PHP version, regardless of the application on top.
Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 7.4, 8.0 and 8.1 received source patches only, and PHP 7.3 and older get no fix. Distribution packages may carry the fix under an older version number, so confirm with your host.
Is PHP2Shell being exploited?
Cloudflare reported early attacks and watchTowr reported exploitation attempts on October 21, the day of the release. The PHP team said the public proof-of-concept code it checked did not work, and Huntress had not seen exploitation across its customers by that evening. Treat it as exploited and patch.
Do I need to update WordPress or my plugins for PHP2Shell?
No. WordPress.org says no WordPress update is required or planned. The fix is a PHP update on the server, which your host applies on managed hosting and you apply on your own server.
Will a security plugin protect my site from PHP2Shell?
No. The demonstrated exploit runs before WordPress loads, so plugins inside WordPress never get a chance to act. Protection has to come from the server (a patched PHP) or in front of it (a web application firewall such as Cloudflare's, as a stopgap).
Sources: Tenable: PHP2Shell frequently asked questions (Oct 21, 2026), Help Net Security: PHP2Shell patched (Oct 21, 2026), Huntress: Rapid response, PHP2Shell (Oct 21, 2026), watchTowr: PHP2Shell FAQ, Codeable: what WordPress site owners need to do (Oct 21, 2026), Patchstack: PHP major vulnerability alert. Host statuses as reported on October 21; check with your host for the current state.