What is PHP2Shell?

PHP2Shell is the name for two serious bugs in PHP itself, the language behind many websites. An attacker with no account can use them to run code on your web server or read data from its memory. A PHP update fixes both.

Last reviewed 22 October 2026. Rules of 22 October 2026.

What you need to know

The bugs are in PHP, not in your site's code. Even a plain "Hello World" page on an affected PHP version can be exposed.
The PHP project says every PHP install that serves web pages is at risk.
The fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, published on 21 October 2026.
Updating WordPress, a plugin or any other app leaves PHP as it was.
After you update, restart Apache, PHP-FPM and any long-running PHP workers.

Each bug has its own CVE number:

CVE-2026-109618: code execution through state that PHP leaves broken when it runs out of memory (advisory GHSA-w8hw-w9fx-j79w).
CVE-2026-109619: code execution through stale state that one request leaves behind for the next, a use-after-free (advisory GHSA-6wmf-4rv5-p3rp).

The PHP project published both advisories on 21 October 2026. The technical write-up explains how each one works.

Who is affected

The PHP project names five ways to run PHP. The table gives what php.net and the two advisories say about each. We added two common servers that php.net does not name, IIS and Caddy, and marked those rows as our own inference.

Sources: php.net advisory of 2026-10-21 and the two php-src security advisories. Rows marked "our inference" are not from php.net.
Server setup	Named by php.net	What is known
Apache with mod_php	Yes	php.net rates it the highest risk. The demonstrated attack needs no login and runs before any application code.
PHP-FPM (often behind nginx or Apache)	Yes	Code execution was shown for CVE-2026-109619, given a suitable operation in the application. For CVE-2026-109618, code analysis shows FPM is at risk, but no complete attack has been shown.
php-cgi	Yes	At risk, says php.net.
FrankenPHP	Yes	At risk, says php.net. Code analysis suggests that, like mod_php, it is open to CVE-2026-109618 without help from the application. No attack has been shown.
LiteSpeed (LSAPI)	Yes	At risk, says php.net. Attacks through a specific application are likely, but none has been confirmed.
Microsoft IIS	No	Our inference: the PHP manual sets up IIS with a FastCGI handler that runs php-cgi, which php.net names. Treat IIS as at risk.
Caddy	No	Our inference: Caddy's `php_fastcgi` passes requests to a FastCGI server, usually PHP-FPM, so the PHP-FPM row applies. Caddy with FrankenPHP: see the FrankenPHP row.

Which PHP versions

On the supported branches, every release before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 is affected.
The PHP project makes no new releases for 8.1 and older. Its security team published small source patches for 7.4, 8.0 and 8.1 only, and the project lists no patch for 7.3 and older.
The researchers say affected releases go back to PHP 5.4.
Linux distributions and hosts ship patched builds, and some keep the old version number. An old number does not always mean an unfixed PHP. Ask your host, or check the package.

The fixed versions page lists every branch and its support dates.

How severe it is

The PHP project rates both CVEs 9.2 out of 10 (Critical) on the CVSS v4.0 scale. The full vector is CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N.

What the vector means:

The attack works over the network.
The attacker needs no account, and no user has to click anything.
The attack is complex and needs certain conditions on the server.
The impact is high: the attacker can read data, change data and stop the service.

What attackers can do

The researchers report three outcomes:

Run code on the server without logging in. The code runs with the rights of the PHP web worker. From there an attacker could take over the server, steal data, deface the site or move on to other systems.
Read PHP process memory. This memory can hold passwords, login tokens, API keys and certificates from other visitors' requests or from the server itself.
Steal data without running code. The memory leak works on its own, so tools that look only for malicious code can miss it.

Why app updates do not fix it

WordPress, Drupal or a custom app is an application that runs on top of PHP. These bugs sit below it, inside PHP.

An update to WordPress core, a plugin, a theme or any other app does not change the PHP version on the server.
A clean, fully updated app on an affected PHP is still exposed.
Your host or server admin has to install the PHP update.

What to do now

Find your PHP version. Look in your app's admin area or your hosting panel. On your own server, check the PHP that serves the site: php -v can show a different PHP from the one your web server uses.
Update PHP. Install 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a newer release in the same branch. A patched build from your Linux distribution or host also works. On PHP 8.1 or older, ask your vendor for a patched build, or move to a supported branch.
Restart PHP. Restart Apache, every PHP-FPM pool and any long-running PHP workers. Our advice for containers: pull the updated image, rebuild your own images on top of it, and recreate the containers. A restart alone does not change the PHP inside an old image.
Check again. Run the checker on your site, and ask your host to confirm the PHP build. If you set memory_limit=-1 as a stopgap, set a finite limit again after the update.
Rotate secrets if the server was exposed. The memory leak can reveal passwords, tokens, API keys and certificates. We recommend rotating every one that PHP could read.

Settings do not fix it.

The PHP project says only the update is a complete fix. Some settings can reduce exposure while you wait, and the mitigations page lists them with their sources.

Demonstrations

The researchers who found the bugs report on php2shell.com:

They ran code without logging in on WordPress, Drupal and Joomla. They used the latest container images of these apps at the time of testing.
CVE-2026-109618 worked on all three apps. CVE-2026-109619 worked on WordPress and Drupal.
The researchers also showed memory disclosure that does not depend on the application.
The three apps were examples. An attack needs none of them.

We do not link to attack code or videos.

Credits

The two php-src security advisories credit these GitHub accounts:

Reporters: lcfr-hax, sagitzadik-wiz, tomash-areion and amyb-oai.
Fix developers: arnaud-lb, iluuu1994, bukka and ndossche.

The researchers' site is php2shell.com, run by Wiz. php2shell.fyi is an independent checker, not affiliated with the PHP project, php.net or php2shell.com.

Sources

Check your site

The checker sends your site ordinary GET requests (at most three) and reports the PHP signals in the response. The normal check sends no attack traffic. Check my site.