PHP2Shell and WordPress: what to do about the PHP flaw

What is PHP2Shell?

PHP2Shell is the name researchers gave to two critical flaws in PHP, the programming language that runs WordPress and most other website software. PHP fixed them on 21 October 2026. On a server running an unpatched version, an attacker can run their own code or read the server's memory without logging in, and researchers showed it working against a default WordPress install.

The two flaws are CVE-2026-109618 and CVE-2026-109619, and the PHP project rates both 9.2 out of 10 on the CVSS scale. Both come from how PHP cleans up when a request fails partway, for example by running out of memory: the first treats half-built data as valid, and the second lets a later request use memory an earlier one already freed. Exploited successfully, either flaw gives an attacker code execution as the site's PHP process, which the researchers say can lead to server takeover, data theft or a defaced site.

The memory-reading variant does damage even without code execution. According to the research team, it can expose passwords, login tokens, API keys and certificates from other visitors' requests or from the server itself, and because no attacker code runs, the theft is harder to detect.

Researchers from Wiz, OpenAI and Calif found the flaws and reported them to PHP. They demonstrated pre-login code execution against the current WordPress, Drupal and Joomla releases, and the research site notes that a simple "Hello World" PHP application on an affected version can be vulnerable too, because the bug sits in the language itself. Wiz says it used AI models throughout discovery and exploit development, and claims "a single researcher completed in a week what previously would have taken a world-class team months of work." Wiz sells security products and has a commercial interest in that claim, though its own timeline puts the first flaw on 19 August and a working attack on WordPress on 21 August.

Is my WordPress site affected by PHP2Shell?

Your site is affected if its server runs PHP 8.1 or older, an 8.2 release below 8.2.35, an 8.3 release below 8.3.36, an 8.4 release below 8.4.27 or an 8.5 release below 8.5.12, whatever version of WordPress you have. In the WordPress dashboard, open Tools, then Site Health, then the Info tab, and expand the Server section to see the PHP version. Then ask your host to confirm in writing that the build includes the fix.

The written confirmation matters because Linux distributions and some hosts backport security fixes into older builds, so the number on the Site Health screen can look older than the fix it contains. Only the host can tell you for certain.

Sites on PHP 8.1 or earlier are in a worse position: the PHP project no longer releases those versions, its security team released minimal source patches for 7.4, 8.0 and 8.1 that a host would have to build itself, and versions 5.4 to 7.3 get nothing from the PHP project. According to Tenable, CISA advises organizations that cannot update right away, or that still run PHP 8.1 or earlier, to take PHP systems offline until they are patched or upgraded.

That group is large: W3Techs counts 26.8% of websites that use PHP still on version 7 and 7.7% on version 5, and the same survey puts WordPress on 39.6% of all websites. PHP 8.2 itself reaches end of life on 31 December 2026, so a site on 8.2 that was patched in October needs another upgrade before the end of the year.

Why doesn't updating WordPress fix PHP2Shell?

PHP is the language runtime installed on the server, and on most hosting plans the host installs and updates it. WordPress core, theme and plugin updates never touch it. A site owner who clicks every update button in the dashboard is still exposed until the host deploys the fixed PHP build for their plan.

The PHP2Shell research site says: "Updating an application does not update the PHP runtime beneath it."

On shared hosting the host patches PHP on its own schedule and the owner cannot speed it up, while on an unmanaged virtual private server the owner is responsible for PHP whether or not anyone said so at setup. A forgotten staging copy or old subdomain on the same account can keep running an old PHP version after the main site is patched.

Security on a typical WordPress business site is split between the owner, the developer or firm who built it, the authors of each plugin and the host, and each of them maintains a separate piece. None of them is responsible for the site as a whole, and nobody in that arrangement is paid to check whether the PHP build under the site picked up a security release on 21 October. Somebody has to hold that job: confirming the PHP version after each security release, applying plugin and theme updates, removing plugins nobody uses, and checking that every account with access to the site uses multi-factor sign-in.

Has PHP2Shell been used to hack websites yet?

Attackers have been trying since at least 17 October 2026, when Amazon recorded a first exploit attempt four days before the fix. Amazon says the flaws are now broadly exploited but that it is unclear whether any attempt succeeded, and as of 23 October no successful compromise had been confirmed. CISA had not observed exploitation when it issued its alert on 21 October.

The CVE numbers and some details leaked online on 20 October, so the PHP project moved its release forward and shipped the fixes on 21 October. Cloudflare's firewall rules went live at 03:02 UTC that day, nearly 11 hours before PHP shipped the fixes at 13:52 UTC, and its CEO said the attempts it saw went from thousands before disclosure to "millions now." Patchstack reported exploitation attempts from hosting partners several hours before the release, and Sophos has since seen attackers try to use the flaws to install a variant of the Mirai botnet malware.

Security researchers who tested the proof-of-concept code circulating online found it did not achieve code execution, and Sansec reported on 22 October that the public exploits fail against PHP installations with default settings. VulnCheck has built an exploit that gets around one of PHP's standard memory protections and offers it to its paying intelligence customers, so working attack code exists even though it is not public. Neither CVE was on CISA's Known Exploited Vulnerabilities list on 23 October.

CJ Moses, chief information security officer at AWS, warned that "defenders should not assume the public disclosure date is the earliest date of exploitation." Every PHP server was unpatched until 21 October, so treat any that was online from 17 October onward as possibly probed.

What should a WordPress site owner do now?

Ask your host to confirm in writing that your server runs PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or a patched vendor build. If you are on PHP 8.1 or older, book the upgrade to 8.3 or newer. Then change the passwords and API keys your site stores, and put a web application firewall in front of the site and leave it on after the host confirms the patch.

Change passwords once the server is patched, because the memory flaw can expose secrets without leaving visible damage, and new passwords set on an unpatched server are open to the same flaw. That list covers the WordPress admin accounts, the database password stored in wp-config.php, and every API key a plugin holds for payments, email delivery, forms, Google and social media.

Ask the host whether its logs since 17 October show the signals the researchers describe: unusual multipart form submissions followed by memory-limit errors or bursts of HTTP 500 responses, unusually large session cookies, or PHP worker processes crashing and restarting. The researchers say these signals do not prove an attack on their own, and their absence does not prove a site is clean. If something looks wrong, bring in an incident response firm before restoring from a backup, so the evidence survives.

Cloudflare switched on a firewall rule for these flaws on every plan, including the free one, which helps only when the site's traffic is routed through Cloudflare. Cloudflare's CTO called the rules a stopgap, and the company tells customers to patch PHP. If you run your own server, PHP's 23 October advisory suggests setting session.upload_progress.enabled=0 until the next release, because a related flaw, CVE-2026-115560, can still allow code execution on patched releases under an unusual configuration. The PHP2Shell research site lists further interim settings.

Why do WordPress sites keep showing up in security news?

Most of the risk on a WordPress site sits outside the core software, in a stack made of a PHP runtime, a database, a theme and plugins from different authors, each updated on its own schedule. Patchstack found 91% of the WordPress vulnerabilities disclosed in 2025 in plugins.

Patchstack's 2026 report counted 11,334 new vulnerabilities across the WordPress ecosystem in 2025, 42% more than in 2024, and only six of them were in WordPress core. Of all 11,334, 46% had no fix from the developer by the time they were disclosed, and for the most heavily exploited flaws the weighted median time to a first exploit attempt was five hours. When Patchstack tested the protections at popular hosts, they blocked only 26% of its attacks.

Unless a caching layer sits in front, a WordPress site runs PHP code and queries its database on most page views, and its login page sits at the same address as the public site, while every plugin runs with WordPress's own permissions and gets security fixes only while its author keeps releasing them.

What does a website built to current security practice look like?

A website built to current security practice serves pages built ahead of time from a global network, so most page views return a stored file instead of running server code against a database. It has no admin login or plugin marketplace on the public site, its software updates go through a reviewed deploy that can be rolled back in minutes, and it forces HTTPS with HSTS and restricts which scripts can run with a content security policy.

A page built ahead of time leaves an attacker little to target, because a malformed request to a stored file returns the same file. The parts that need a server, such as a contact form or a booking request, run as small functions that accept a fixed set of fields, check them and limit how often one visitor can submit. With no public admin login, there is no password page for bots to guess at.

The software the site depends on is pinned to exact versions and scanned automatically for known vulnerabilities, and updates go through a build that runs its checks before anything goes live. If an update breaks something, the previous build goes back up in minutes, and the repository history also serves as a backup of the site's code and content.

HSTS tells browsers to refuse insecure connections to the site, and a content security policy limits which scripts a page is allowed to load, which makes attacks that inject a script into the page much harder to carry out. API keys sit in the hosting platform's encrypted secret store rather than in a configuration file on a web server, and the accounts that control the site, meaning the domain registrar, DNS, hosting and Google, use multi-factor sign-in, because whoever holds the registrar password can point the domain anywhere without exploiting any software flaw. The practical step for an owner is to ask whoever runs the site which of these are in place and who applies a security fix when one ships.

Are modern frameworks like Next.js immune to these attacks?

No. In December 2025 a critical flaw called React2Shell let attackers run code on Next.js applications built with the App Router, and CISA listed it as actively exploited within days. On a site with a small, version-controlled codebase, the repair was one dependency update, a redeploy and a rotation of secrets, done by the team that owns the code.

React2Shell was disclosed on 3 December 2025 and rated 10.0, the maximum, and Next.js shipped patched releases the same day, two days before CISA added the flaw to its exploited list on 5 December. The Next.js advisory listed the Edge Runtime and Pages Router applications as unaffected, and told everyone else to patch, redeploy and then rotate the secrets their application uses, the same order PHP2Shell calls for.

Attackers have the same AI tools Wiz describes, and Patchstack measured a five-hour weighted median from disclosure to first exploit attempt for the most heavily attacked WordPress flaws of 2025. On any platform, a site stays exposed from the day a fix ships until someone applies it, so the owner needs to know who that person is and how quickly they act.

Should you move your business website off WordPress?

Stay on WordPress if you have a developer on retainer, a short plugin list and a host that applied the PHP fix on the day it shipped. Consider moving if the site is mainly informational pages with a contact form on shared hosting, and nobody can tell you which PHP version it runs or who updates it.

Large online stores and membership sites built deep into WordPress plugins are expensive to move, and for those the better step is usually a managed host and a maintenance contract with a named developer. Brochure-style business sites are the opposite case, because they use very little of what WordPress offers and still carry the full stack of PHP, database, theme and plugins underneath. A rebuild keeps the domain and the business email, and most search ranking carries over as long as every old URL is redirected to its new equivalent, while the old site stays up until the new one is ready to replace it. Our WordPress comparison sets out what each option costs and who does the upkeep.

How does MannVenture build and maintain websites?

MannVenture's AI Website is built on Next.js and runs on Cloudflare's network. Hosting, SSL, security updates and two content edits a month are included for $97 CAD a month, plus a one-time $497 implementation fee. Our team rebuilds on your existing domain, so your web address and business email stay the same.

Every AI Website forces HTTPS with HSTS, has no admin login on the public site and builds its pages ahead of time wherever the content allows. Our team applies framework security releases through a reviewed build, so security fixes go live without the client asking for them.

Each site also includes an AI agent that answers visitor questions, gives price ranges and books work. The first preview arrives 48 hours after the kickoff call. See what the AI Website includes.