PHP2Shell is the nickname for two critical vulnerabilities in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. They can let an attacker run code on a web server without logging in, and they affect almost every PHP version back to 5.4. The PHP project shipped fixes on October 21, 2026 (PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35), and exploitation attempts started within hours. If your website runs on PHP, which includes every WordPress and WooCommerce site, confirm today that your server is on a patched build.
This is a server-level problem. Updating WordPress, your theme or your plugins does not fix it. The fix has to come from whoever runs the server: your host, your IT team or your developer.
Below is what we know so far, with sources, and a plain checklist for business owners.
The short version
| Question | Answer |
|---|---|
| What | Two remote code execution flaws in the PHP runtime |
| CVEs | CVE-2026-109618 (out-of-memory corruption), CVE-2026-109619 (stale global state) |
| Severity | CVSS v4.0 9.2 (critical) for both |
| Affected | PHP 5.4 through 8.5, before the fixed releases below |
| Fixed in | PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 (released October 21, 2026) |
| No official fix | PHP 8.1 and older (source backports exist for 7.4, 8.0 and 8.1) |
| Exploited? | Exploitation attempts seen before and after disclosure |
| What fixes it | Updating PHP. Configuration changes only reduce the risk. |
Sources: the PHP security advisory, and GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.
What are the two vulnerabilities?
Both bugs are in the PHP engine, the software that runs your site's code, not in any particular application. That's why even a simple, well-written PHP page on a vulnerable server is exposed.
CVE-2026-109618: memory corruption when PHP runs out of memory. If PHP hits its memory limit partway through setting up a request, some internal data can be left half-built. Cleanup code then trusts that broken data, which researchers showed can be turned into remote code execution. PHP says the risk is highest on Apache with mod_php, where a demonstrated exploit works with a single request before any of your application's code runs.
CVE-2026-109619: stale state between requests. Some data belonging to one request can outlive the memory it points to. The next request handled by the same PHP worker can then act on that leftover data, a classic "use-after-free" bug. Researchers demonstrated code execution on both mod_php and PHP-FPM, though the FPM path depends on what the application does. The confirmed attack paths go through PHP's session upload progress feature, which is on by default.
Researchers also showed that the flaws can leak memory from other requests. That means passwords, session tokens and API keys could be exposed even where an attacker can't run code (The Hacker News, Qualys).
PHP lists every setup that serves web requests as in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed (watchTowr).
Who found it, and how did it become public?
The bugs were found by researchers at Calif, Wiz Research and OpenAI, with other teams helping on the fix. The underlying code had been in PHP for more than a decade. The researchers say AI models helped them turn the flaws into working exploits much faster than a team could have by hand (The Hacker News).
Disclosure didn't go to plan:
- October 17: Amazon's honeypots recorded an exploitation attempt, four days before public disclosure. Amazon says it's unclear how the attacker got the information, or whether the attempt would have worked on a real system (AWS Security Blog).
- October 20: The CVE numbers leaked online ahead of a planned October 22 disclosure. PHP posted an advance notice and moved the release up a day.
- October 21, 03:02 UTC: Cloudflare switched on firewall rules for all customers, including free plans, as a stopgap (Cloudflare).
- October 21, 14:00 UTC: PHP released the fixes and published its advisories.
- Within hours: watchTowr and Amazon reported exploitation attempts against their sensors, and Cloudflare saw attackers changing payloads to get around its rules.
The PHP Foundation said signs of the first bug surfaced during a 2024 security audit, but the fix stalled for months. It called the delay a structural failure and says it has changed how it handles security decisions (The Hacker News).
Is it being exploited?
Yes, attempts are widespread. Whether they're succeeding is less clear.
- Amazon describes broad exploitation attempts in the wild since the patch release (AWS).
- watchTowr has seen exploitation in its honeypot network since October 21 (watchTowr).
- Cloudflare reported attack traffic against its customers (Cloudflare).
- As of October 22, CISA had not added either CVE to its Known Exploited Vulnerabilities catalog, and no source had confirmed a successful break-in.
Some organizations took services offline to patch, including the HR platform BambooHR and several Dutch government services such as DigiD (The Hacker News). Treat this as urgent, not as a "next maintenance window" update.
How many sites are affected?
A lot. PHP runs most of the web, and many servers run old versions.
- About 2.24 million internet-facing hosts advertise PHP. Of those that show a version, 59% run a branch with no official fix: PHP 5.x, 7.x, 8.0 or 8.1 (CybelAngel, based on Shodan data).
- Across its customers, Qualys found 71% of PHP installations with a known version on end-of-life branches, and only a tiny share patched in the first 12 hours (Qualys).
Shared hosting puts many sites behind one server, so the real number of websites is higher than the host counts.
Does this affect WordPress and WooCommerce?
Yes. WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel apps and hosting panels like cPanel and Plesk all run on PHP. The bug isn't in WordPress. It's in the PHP version your server uses, so:
- WordPress auto-updates won't fix it. Neither will updating plugins or installing a security plugin.
- On shared or managed hosting, your host patches PHP. Many large hosts patched quickly, some before the public release. Confirm it with yours rather than assuming.
- On a VPS or dedicated server, whoever manages the server has to update PHP and restart it.
If your site is still on PHP 7.x or 8.0/8.1, you have a bigger job: those versions get no official fix. You'll need a vendor or distribution that backports the patch, or, better, an upgrade to a supported version. That can break old themes and plugins, so test it on a copy of the site first. Our WordPress development team and WooCommerce developers do these upgrades regularly.
How to check if your site is vulnerable
1. Find out which PHP version serves your site.
- WordPress: go to Tools → Site Health → Info → Server and look at "PHP version".
- cPanel or Plesk: look for "Select PHP Version" or "MultiPHP Manager".
- On the server:
php -vshows the command-line version, which may not be the one serving web requests. Aphpinfo()page (removed right after) or your web server config is more reliable.
2. Compare it with the fixed versions.
| Your branch | Safe from |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 (and plan an upgrade: 8.2 reaches end of life December 31, 2026) |
| PHP 8.1 and older | No official release. Use a vendor backport or upgrade. |
3. If you use a Linux distribution's PHP packages, the version number may look old even when it's patched, because distributions backport fixes. Check the package changelog for the two CVE numbers instead of trusting the version string.
4. Ask your host in writing: "Is our PHP build patched for CVE-2026-109618 and CVE-2026-109619, and when were PHP workers restarted?"
What to do now
- Update PHP to the fixed release for your branch. This is the only complete fix. In PHP's words: "There are no complete mitigations, updating is the only safe choice."
- Restart every PHP worker (PHP-FPM pools, Apache) so the patched code is actually running.
- Prioritize internet-facing servers, starting with any running Apache mod_php.
- Re-check your memory settings after updating. The fix adds a hard memory limit that ends the process when it's reached, so review
memory_limitandpost_max_sizeagainst what your site needs. - Keep your firewall rules on. Cloudflare and other web application firewalls block known attack patterns, but they don't replace the patch.
- Look for signs of an earlier break-in (see below), because attempts started before the patch existed.
If you can't patch today
PHP has published temporary settings that reduce the risk but don't make a server safe (PHP advisory):
; php.ini or PHP-FPM pool (set as admin values so apps can't override them)
memory_limit = -1
post_max_size = 8M ; 32M if the site needs uploads
upload_max_filesize = 8M ; must stay below post_max_size
session.upload_progress.enabled = 0
On PHP 8.5, also set fatal_error_backtraces = 0. Restart all workers afterward; setting these from application code with ini_set() or a .user.ini file doesn't work. Turning memory_limit off has its own risks, so treat this as a stopgap for hours or days, not a fix. If a server can't be patched or mitigated, restrict public access to it until it can.
Signs your server may have been hit
Researchers suggest looking for (The Hacker News, AWS):
- unusual multipart (file upload) requests followed by memory-limit errors or bursts of HTTP 500 errors
- POST requests containing
PHP_SESSION_UPLOAD_PROGRESSin your web server logs - unusually large
PHPSESSIDcookies in responses - PHP workers restarting for no clear reason
- unexpected processes, new files or changed files on the web server
Amazon recommends starting any investigation from October 17, the earliest known attempt, not from the disclosure date. If you find something, change the passwords and API keys the site uses, check for new admin users, and restore from a clean backup if files were changed. Our security and malware cleanup service handles exactly this.
One more PHP issue to know about: CVE-2026-115560
On October 23, PHP published an informational advisory about a related flaw in session upload progress, tracked as CVE-2026-115560. It affects even the newly patched releases, but only when an application switches PHP's session serializer at runtime and upload progress is enabled. Most sites don't do this. PHP suggests keeping session.upload_progress.enabled=0 until the next regular release (PHP, Cloudflare).
The bigger lesson: someone has to own your server
The sites most at risk this week aren't the ones with bad code. They're the ones where nobody is sure who updates PHP, or where the server has been on PHP 7 for years because "it still works". The same was true for the Railway breach this week, where the work fell on customers to rotate their own secrets.
When you choose a web development company, ask who patches the server and how fast. And when you budget for a site, remember that maintenance is part of the cost, not an extra.
Need help checking your site?
Prodjex has built and maintained PHP, WordPress and WooCommerce sites since 2017. We can check which PHP version your site actually runs, confirm whether it's patched, and handle the update or a PHP upgrade, including testing your theme and plugins first. Our care plans cover server updates like this on an ongoing basis.
Contact us about your site and tell us your website address. See also our PHP development services.
Sources
- PHP: Security advisory, October 21, 2026, advance notice, October 20, session upload progress advisory, October 23
- GitHub security advisories: GHSA-w8hw-w9fx-j79w (CVE-2026-109618), GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- The Hacker News: PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws
- Amazon: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure
- watchTowr: PHP2Shell FAQ
- Qualys: How to Find, Mitigate, and Patch PHP2Shell
- Cloudflare: PHP vulnerabilities and WAF protection
- CybelAngel: 2.24M internet-facing PHP hosts
- Also useful: Tenable FAQ, Rapid7 analysis, SANS Internet Storm Center
This post reflects what was public as of October 23, 2026. We'll update it as PHP, CISA and researchers publish more.