PHP2Shell: What the PHP Flaw Means for Your Website, and What to Do Today

A flaw in the engine, not in the car

Most website security news is about a plugin. This one is about the floor the plugins stand on. PHP2Shell is a pair of flaws in PHP itself, the programming language that runs most WordPress, Drupal, Joomla, WooCommerce and Magento sites, along with a great many custom sites built in the last fifteen years. Your theme did nothing wrong. Your plugins did nothing wrong. The interpreter reading them had a hole, and on an unpatched server it still does.

The specifics. The PHP project tracks the bugs as CVE-2026-109618, where out-of-memory handling can interrupt PHP while internal request data is only partially initialized, and CVE-2026-109619, a use-after-free in which request-owned state survives after the memory behind it has been freed. Both carry a CVSS v4.0 score of 9.2, which the project rates critical. Wiz Research, which found the bugs and gave them the name, says the two CVEs cover four separate bugs.

What they allow is the part that earns the name. Under the right conditions, an attacker with no account and no password sends a request, and the server runs the attacker's code: a shell. Wiz also showed a quieter variant that discloses the server's process memory without running anything. Memory is where passwords, tokens and API keys sit while a site does its work, so a leak is not a small consolation prize.

Who is exposed, and who gets to skip this

The PHP project's list is short because it is total. At risk are "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed," with risk highest for mod_php. Wiz adds that even a "Hello World" app on an affected version can be vulnerable, and that the upload-progress path works even when the application never calls `session_start()`. Good code on top does not save a bad interpreter underneath.

How much of the web is that? Wiz says PHP powers roughly 70% of websites. According to Qualys, which reported counting about 167 million PHP installations, 73% are internet-facing and 71% run versions past end of life. The second number matters more than the first: a site on PHP 7.4 or 8.0 gets no release from the PHP project at all, which is its own problem with its own page, old PHP past end of life. Three groups can stop worrying early:

• Sites with no PHP on the public server. Static sites, a Next.js site served from an edge network, and hosted platforms such as Shopify, Squarespace and Wix, which do not run customer PHP code.
• Sites already on a fixed release. PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a distribution package with the fix backported. Confirm it rather than assume it with the five-minute version check.
• That is the whole list. A fully updated WordPress with a security plugin and a firewall is still running the old interpreter underneath. Here is why WordPress, Drupal and Joomla are all in this.

Four moves, in this order, starting today

The order matters more than the speed. Updating closes the hole for good, so it goes first. Mitigations only narrow the hole, so they come second and only if the update must wait. The compromise check comes third, because a patched server can still be carrying something that arrived before the patch. The long-term decision comes last, once nothing is on fire.

1. 1

   Update PHP to a fixed release

   On shared hosting the host installs the build and you choose it per site: patching on cPanel, Plesk and managed WordPress. On a VPS or in containers, the update, the restart and the image rebuild are yours: patching a VPS or a Docker image.

2. 2

   Narrow the exposure if the update has to wait

   Turn off session upload progress where applications cannot override it, cap memory and request sizes, and put a firewall rule in front. The PHP project calls these partial. The interim settings, line by line.

3. 3

   Look for signs someone got in first

   Memory-limit errors after odd multipart requests, repeated 500 errors, oversized PHPSESSID cookies, PHP workers restarting for no reason. What a compromise looks like and where to look.

4. 4

   Decide what the site should run on next year

   PHP 8.2 reaches end of life on December 31, 2026. If the site is stuck on old PHP, or you would rather not repeat this week, there is a route that takes PHP off the public internet while editors keep their dashboard.

The fixed releases, branch by branch

PHP ships in branches, and each supported branch got its own fixed release on October 21, 2026. The number you need is the one on your branch. A site on 8.3 does not have to leap to 8.5 tonight; it needs 8.3.36. Anything older on the same branch is vulnerable.

One wrinkle trips careful people. Linux distributions backport fixes into their own packages, so `php -v` on a patched Debian or Ubuntu server can show an older-looking number that is in fact fixed. Check the distribution's security tracker for the CVE ID, not the version string. The reverse happens too: a control panel can say "8.3" while the host is still running an 8.3 build from before the fix. The full version check covers both.

Nine weeks from discovery to a Wednesday release

According to Wiz, the flaws sat in plain sight for more than a decade, in code nearly every PHP version since 5.4 shares. Plenty of capable people read that code over the years. Then Wiz Research went looking with the help of AI models, and the company says work that would have taken a team months took one researcher about a week. Somewhere, a decade of code review is quietly asking for a recount.

• August 19, 2026: Wiz finds the first bug.
• August 20 and 21: unauthenticated code execution confirmed against Drupal, then WordPress.
• August 24: the bugs are reported to the PHP security team.
• September 21: the PHP project acknowledges the reports.
• October 20: advance notice of a critical release.
• October 21, 14:00 UTC: fixed releases ship and the details go public.
• October 23: a follow-up advisory for a separate, less likely issue, CVE-2026-115560.

Wiz's demonstrations ran against the official latest Docker images of WordPress, Drupal and Joomla at the time of testing, which is to say the versions a careful person would have picked. The October 23 issue needs an unusual setup, an application that changes the session serialize handler at runtime. The project's advice for it is the same setting it already gave, `session.upload_progress.enabled = 0`, until the next regular release. If you set it this week, you are done with that one.

For readers who want the primary sources: the PHP project's announcements, the GitHub advisories for CVE-2026-109618 and CVE-2026-109619, and Wiz's research post. Our running notes on site security live under web security.

Attempts now, breaches later: why this outlasts the news cycle

Within a day of disclosure, security firms reported attack attempts against their sensors and honeypots. Cloudflare was among those that observed them, and most aimed at the session upload-progress path. On October 22, NBC News reported that several security firms had not seen a confirmed successful attack, and that exploitation is difficult because it depends on chaining bugs and on how a server reuses its workers. CISA had not added the CVEs to its Known Exploited Vulnerabilities catalog as of October 21. All of that can change any day.

The people paid to watch expect it to. In a CNBC video interview on October 23, CrowdStrike's chief executive said the industry "will see a lot of breaches in coming months" from the PHP vulnerability. Read that as the calendar for this problem: months, not a news cycle. The headlines will move on next week. The unpatched servers will still be there in February, and so will the people scanning for them.

The host's status page says all systems normal. It said that on Tuesday, too.

Two details from CrowdStrike's own analysis explain why a quiet log is weak comfort. On Apache with mod_php, a single unauthenticated POST request can be enough to start a shell. And the attack traffic can come back as ordinary 200 responses, so the access log looks like a normal day. Patching today is a bounded job with a known price. A breach discovered in the spring is neither.

Vendors moved quickly. Wiz says Cloudflare, Fastly, Google, Vercel and others published guidance and out-of-the-box mitigations for organizations that cannot patch immediately, and Google Cloud published guidance for Cloud Armor, containers and App Engine. A firewall rule in front of an unpatched server buys time. It does not replace the update, because a rule can only match the attacks someone has already described.

Find your page in this section

Nine pages, each written for one situation. Start with the one that sounds most like your week, and come back here when you need the next step.

Check and patch

Assess and decide

How DataCram handles it: the patch today, the exit after

We are a web studio in San Antonio, Texas, working with businesses across the US, and this week the job is unglamorous: get PHP to a fixed release, prove it, and make sure nothing broke on the way. The PHP2Shell emergency fix updates PHP or moves the site to a host or plan that offers a fixed build, applies the interim settings when the update has to wait, tests the site afterward, checks for signs of compromise and cleans up when needed.

The Fix It Now prices are for WordPress sites. Drupal, Joomla, Magento and custom PHP sites get a free check and a quote. Call (210) 346-0848, or use the form below. Our free website health check gives a quick outside look at security, speed and search basics; it is not a PHP2Shell scanner and cannot read a version the server hides, so treat it as a second opinion, not a verdict. If you suspect a break-in, go straight to malware removal and website security.