Primary source: The PHP Foundation, “Today's PHP Security Release, and How We're Strengthening PHP Security”, October 21, 2026. For the technical detail, see Wiz Research and the GitHub advisories.
On October 21, 2026, the PHP project released an emergency update for two critical vulnerabilities that allow unauthenticated remote code execution. The next day, the story was in mainstream media worldwide, with governments reviewing public services, companies taking parts of their infrastructure offline and security teams hunting for unpatched servers.
The name that stuck is PHP2Shell. It is not a WordPress, plugin or theme problem: it lives in the PHP interpreter core. That is what makes it different, and why you need to check the server runtime, not just the CMS version.
What happened, in order
- October 20: CVE-2026-109618 and CVE-2026-109619 began circulating on forums and social media before the coordinated announcement. PHP brought its pre-announcement forward and moved the release one day earlier.
- October 21, 14:00 UTC: PHP published versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with the fix.
- October 21–22: CISA, CERT-EU and the UK NCSC issued alerts. Wiz published its technical analysis, OpenAI and Calif explained their role in the research, and outlets such as BBC and The Guardian reported outages and millions of exploitation attempts.
- October 22: the story reached mainstream front pages. Wikipedia took down parts of its site as a precaution and several European governments suspended public services, according to BBC.
The situation kept changing after publication. CISA had not observed exploitation when it issued its alert, but The Guardian reported millions of attempts and public proof-of-concept code was already circulating. In an incident like this, the window between “a patch exists” and “exploitation exists” can be measured in hours.
What the two vulnerabilities actually are
Both were rated CVSS 9.2 by the PHP security team. Both are memory-safety flaws in the PHP engine, related to how fatal errors and out-of-memory conditions are handled.
| CVE | Technical name | What it allows |
|---|---|---|
| CVE-2026-109618 | RCE via OOM corruption | Corrupt memory and execute code; also disclose process memory |
| CVE-2026-109619 | RCE via stale global state | Reuse global state pointing to freed memory and execute code on a later request |
The detail that matters to a business is not the internal mechanics but the scope:
- No authentication required. On Apache with
mod_php, CVE-2026-109618 can be triggered before application code runs. Remote code execution was also confirmed on PHP-FPM through application-level paths. - It does not depend on WordPress, Drupal or Joomla. Wiz demonstrated exploitation on all three, but also warned that a “Hello World” application on a vulnerable version can be exposed. The flaw sits below the application.
- It can leak memory. Besides code execution, one variant allows reading process memory, which may contain passwords, tokens, API keys and certificates from other requests.
- It affects old versions. Wiz says every PHP release from the last decade, going back to PHP 5.4, is affected by at least one of the two. PHP only maintains patches for 8.2, 8.3, 8.4 and 8.5; PHP 8.1 and earlier received no official fix.
Wiz estimates that PHP powers around 70% of websites. It is an industry estimate, not a census, but it explains why a vulnerability in the interpreter becomes a global infrastructure problem.
Why this one is different
Every few years a vulnerability changes the conversation: Heartbleed in OpenSSL, Log4Shell in Java. PHP2Shell has a similar component: the flaw sits in a layer almost everyone takes for granted.
The difference is that this research used AI models to find and chain bugs that had been in the code for more than a decade. The PHP Foundation describes it as an inflection point: tools now find flaws faster for defenders and attackers alike. That does not mean “AI broke PHP”; it means the economics of finding and exploiting complex flaws have changed.
For a small team, the practical lesson is uncomfortable: runtime security is not delegated to the CMS. WordPress can be fully updated while the server still runs a vulnerable PHP version.
What to do now
1. Inventory everything running PHP
Checking the main website is not enough. PHP is often hidden in:
- the hosting for the corporate site and the store;
- Docker images and containers;
- internal applications and legacy panels;
- serverless functions or managed services;
- plugins or tools that ship their own runtime.
CISA recommends identifying and inventorying any system running PHP, because it is often not directly visible from the outside.
2. Update to a patched version
The patched versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you use managed hosting, open a ticket and ask for written confirmation of the PHP version and the date it was applied. If you run the server, update the package and restart PHP-FPM or the web server as appropriate.
If you are on PHP 8.1 or earlier, there is no official patch. The only way out is migrating to a supported version. Keeping an unsupported version after a disclosure like this is not a technical decision: it is an open exposure.
3. If you cannot update today
CISA recommends taking exposed PHP systems offline until they can be patched. If that is not viable:
- isolate the service with network rules and restrict access;
- apply WAF rules as a temporary mitigation;
- monitor intensively;
- plan the update with a concrete date.
A WAF reduces exposure, but it does not remove the vulnerability. Do not treat it as the final fix.
4. Check the version on WordPress
The PHP version is not in the WordPress dashboard; it is on the server. These are the fastest ways to check:
php -v
If you have WP-CLI:
wp --info
In the WordPress dashboard, go to Tools → Site Health → Info → Server and look for the PHP version. On managed hosting, you will find it in hPanel, cPanel or the PHP configuration section.
If you use Docker:
docker exec -it <container-name> php -v
Hiding the PHP version in HTTP responses is not a mitigation. It does not change the code being executed.
5. Look for signs of compromise
The flaws sit below the application, so CMS logs may have little context. Wiz recommends reviewing:
- unusual multipart requests followed by
memory_limiterrors or repeated 500 responses; - unexpectedly large or malformed
PHPSESSIDcookies; - abnormal PHP worker crashes and restarts;
- PHP processes launching shells or downloading tools;
- unusual activity in Apache, PHP-FPM, LiteSpeed or proxy logs.
If there are signs of exploitation, do not delete logs. Isolate the system, preserve evidence and rotate credentials, tokens and keys that were present on that server.
6. Review the full chain
After patching, check:
- administrator users and scheduled tasks you do not recognise;
- modified files in WordPress, plugins, themes and upload directories;
- outbound connections and service accounts;
- API keys, passwords and certificates that may have been in memory.
Fixing the interpreter closes the entry point, but it does not undo access that already happened.
What not to do
- Do not assume updating WordPress updates PHP. They are different layers.
- Do not rely on a WAF alone. It is a temporary mitigation, not a patch.
- Do not install proof-of-concept code from unknown sources. Public PoCs can also be an infection vector.
- Do not stay on PHP 8.1 or earlier hoping the host will fix it on its own.
- Do not delete logs or rebuild the server before preserving evidence if you suspect compromise.
How to cite this article
If you use this analysis in an internal report, newsletter or article, you can cite it as:
Coderwebs. “PHP2Shell: what happened with the critical PHP vulnerability and what to do now”. October 23, 2026. https://coderwebs.com/en/blog/php2shell-php-vulnerability/
The primary and technical sources are listed below. If your team needs help inventorying versions, reviewing WordPress or prioritising the update, you can talk to us or see how we approach WordPress maintenance.
Conclusion
PHP2Shell is not a story about an outdated plugin. It is a story about an infrastructure layer that supports a huge part of the web and that many companies do not review until there is an emergency. The right response has three steps: patch first, investigate second and monitor continuously.
If your site runs WordPress, the question is not “am I on the latest WordPress version?”. The question is “which PHP version is the server running, and who updates it?”.