PHP2Shell: what to do if your website runs on WordPress (or any PHP)

What PHP2Shell is, in plain terms

On October 21, 2026 the PHP project released emergency fixes for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, together nicknamed PHP2Shell. Both are rated 9.2 on the CVSS v4 scale, which puts them in the critical band. They were found by Wiz Research working with OpenAI, Calif, and Google, and the researchers used AI tooling to find and prove the bugs in a fraction of the usual time.

The bugs live in how PHP handles a request that runs out of memory. When that happens, PHP can leave stale internal state behind, and the next request to the same worker reuses it. The researchers chained that into two outcomes: running code on the server without logging in, which they demonstrated against stock WordPress, Drupal, and Joomla installs, and reading chunks of the PHP worker's memory, which can contain passwords, session tokens, and API keys from other people's requests.

Because the flaw is in the PHP engine, it does not matter how careful your theme or plugins are. A site with no plugins and a perfectly clean codebase is exposed if the PHP underneath it is unpatched. PHP runs roughly three quarters of the websites with a known server-side language, which is why this is being treated as an internet-wide event.

Who is affected

Every PHP release going back to 5.4 is affected by at least one of the bugs. These are the first fixed versions:

If you run WordPress, Drupal, Joomla, Magento, Laravel, Symfony, Moodle, Nextcloud, MediaWiki, or anything else written in PHP, this applies to you. If your site is on Squarespace, Wix, Shopify, or Webflow, it is not built on PHP and this particular bug does not apply. If someone built you a custom site and you are not sure what it runs on, ask them; the answer should take them ten seconds.

Step 1: find the PHP version that actually serves your site

In WordPress, sign in and go to Tools, then Site Health, then the Info tab. Open the Server section and read the PHP version. Other platforms have an equivalent system information page, or your hosting control panel will show it.

Two cautions. First, if a developer checks by running php -v on the server, that can report a different interpreter than the one behind the web server. The Site Health number is the one that matters. Second, a lower-looking number is not always bad news. Ubuntu, Debian, and some hosts apply security fixes without changing the version string, so a site reporting 8.1.x may already be fixed. In that case you need the host or the distribution's security notice to confirm it.

Step 2: ask your host, in these exact words

If you are on shared or managed hosting (GoDaddy, Bluehost, SiteGround, WP Engine, Kinsta, Flywheel, Hostinger, DreamHost, and the like), you cannot upgrade PHP yourself in most cases, and the host has to do it. Open a support ticket and ask:

Has the PHP fix for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) been installed on the server that serves my site? Which PHP version is it running now?

There is one answer you should not accept as final: "We have added firewall protection." A web application firewall can block the known exploit patterns, and that is worth having while you wait, but the researchers and the PHP team are both clear that it is a stopgap, not a fix. The bugs sit below the application layer, and a different request shape can get past a rule. Keep the ticket open until the host tells you PHP has been updated to a fixed release.

Most of the large managed WordPress hosts announced protection or rolling patches on day one, and Automattic said its WordPress.com, VIP, and Pressable platforms were already covered. Status changes by the hour, so check your host's status page rather than trusting a screenshot from a forum.

Step 3: if you run your own server

On a VPS, a cloud instance, or a Docker host, the fix is yours to apply.

1. 1.Install the fixed PHP packages from your Linux distribution or from the PHP project's repositories, then confirm the version with your package manager.
2. 2.Restart PHP-FPM, Apache, or whatever serves PHP. The running processes keep executing the old code until they restart.
3. 3.If PHP runs in Docker, pull the fixed image and recreate the containers. A pull on its own changes nothing that is running.
4. 4.Re-check Site Health (or the equivalent) to confirm the served version changed.

Step 4: if you are on PHP 8.1 or older

PHP 8.1 reached the end of its security support before this disclosure, so there is no official fixed release for it or anything older. A few distributions and hosts are backporting a fix; if yours is not, the realistic path is to move to PHP 8.3 or 8.4. Before you flip that switch: take a full backup, update WordPress core, your theme, and every plugin, change the PHP version in your hosting panel, then click through the pages that make you money (home, contact form, checkout, booking). Old plugins are the usual thing that breaks.

While you wait: things that reduce exposure

None of these replaces the PHP update. They narrow the attack paths the researchers used, and they are the kind of thing a host or a developer can do in minutes.

• Put the site behind Cloudflare or another CDN with a web application firewall, and make sure traffic actually goes through it (the origin server should not be reachable directly).
• Ask the host to turn off session.upload_progress, set display_errors to off, and disable fatal error backtraces. The exploit paths run through upload progress handling and error output.
• Lower post_max_size and max_input_nesting_level, and reduce pm.max_requests so PHP workers recycle more often and stale state lives for less time.
• The PHP team's advisory also recommends memory_limit = -1 combined with a container memory limit. That one is for people who run their own servers and understand the trade-off.

After patching: assume the fix does not undo what already happened

The bugs were reported to PHP on August 24 and patched publicly on October 21. There is no public evidence yet of exploitation in the wild during that window, but the exploit is now documented and scanners move fast. A backdoor planted before the fix is still there after it. If your site was unpatched for any time after disclosure, or you see signs of trouble, do a compromise check:

• Look in your server logs for unusually large or malformed PHPSESSID cookies, bursts of multipart (file upload) requests followed by memory-limit errors or repeated HTTP 500 responses, and PHP workers crashing and restarting for no reason.
• Check WordPress for admin users you did not create, plugins and theme files modified recently, and unexpected scheduled tasks. A file-integrity scan against clean copies of core and plugins is the fastest way to spot injected code.
• Because the memory-disclosure bug can leak secrets, rotate the things that would hurt if leaked: the database password, API keys stored in wp-config.php or plugin settings, SMTP credentials, and the WordPress salts (which signs everyone out, which is the point).
• If you find anything, restore from a backup taken before the exposure window, patch PHP, then rotate secrets again.

If you look after many sites

Agencies, IT shops, and anyone with a fleet of client WordPress sites have the same problem multiplied by the number of hosts involved. Build a sheet with one row per site: domain, host, PHP version from Site Health, who has access to the hosting account, patch status, and the date you confirmed it. Then work through it host by host rather than site by site, because the answer from one ticket usually covers every site on that host. Keep the sheet; the next one of these is a matter of when.

If you would rather hand this to someone

We do this work. For a single site, that is a check of what is actually running, the host conversation, the interim hardening, and a compromise sweep, with a written summary at the end. For an agency with a list of client sites, it is the same thing run as a batch, under your name if you prefer, through our white-label service. And if the site has been limping along on an old PHP version with a stack of abandoned plugins, we will tell you straight whether patching it is worth it or whether a rebuild on our process would cost about the same and end this cycle. Start with the contact form or call; replies come from the engineer, not a queue.