Nesma

PHP2Shell vulnerability: what to do with your PHP site

Sergey Nesmachny
Sergey Nesmachny
22.10.2026
6 min read
PHP2Shell vulnerability: what to do with your PHP site

PHP2Shell is the name for two critical flaws in the PHP interpreter itself, CVE-2026-109618 and CVE-2026-109619. Under the right conditions they let an attacker run code on your server without logging in. Fixes shipped on October 21, 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your site runs on PHP, update it today. Sites built on EmDash are not affected, because there is no PHP in them.

Below: what happened, what to do with a PHP site right now, and whether this is a reason to change your CMS.

What happened

Researchers at Calif and Wiz found the bugs in August and reported them to the PHP team. Coordinated disclosure was planned for October 21, but the details leaked a day early. On the morning of October 21 Cloudflare reported the first exploitation attempts. The fixes came out at 14:00 UTC the same day.

Both flaws are rated 9.2 out of 10 on CVSS v4.0, and watchTowr scores them at the full 10. They go back to PHP 5.4, which covers almost every PHP server on the internet. Wiz estimates that about 70% of web resources are exposed. The US agency CISA published an alert asking for immediate patching.

The important detail is where the bug lives. It is not in WordPress, WooCommerce or a plugin. It is in the interpreter that runs every PHP application. Application-level protection does not help: according to Datadog, PHP processes the malicious request before your code ever sees it. One of the two flaws can also leak server memory through the PHPSESSID cookie, even if your site never starts a session.

Why governments took sites offline

The reaction was unusually sharp. Finland, the Netherlands, France, Germany and Belgium pulled parts of their government websites offline as a precaution. The Wikimedia Foundation suspended some of the systems behind Wikipedia. Japan's prime minister told site operators to update immediately or take their sites down if they could not.

Sansec offers a calmer view. Mass exploitation looks less likely than it did on day one: the public exploits do not work against a default PHP installation, and most of them need a second bug in the site, such as a local file inclusion. That is no reason to wait. It is a reason not to panic.

What to do with a PHP site today

If your site runs on WordPress, WooCommerce, Drupal, Joomla, Magento or any other PHP stack, a migration can wait. Close the hole first:

  1. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. This is the only complete fix, and you cannot apply it from your site's code. For 7.4, 8.0 and 8.1 the PHP team published source patches only; ready-made packages come from your Linux distribution or hosting panel, for example Plesk.
  2. On shared hosting, ask support whether they have updated PHP and which exact version you are on. On a shared server the host installs the interpreter, not you.
  3. If you cannot update right now, set session.upload_progress.enabled to off and temporarily block multipart/form-data requests at the web server. The second step breaks file uploads and some forms, so test your checkout and remove the rule after patching.
  4. Check that the update took effect. Run php -v on the server or look at a temporary phpinfo() page, then delete it. Restart PHP-FPM or Apache, otherwise the old process keeps serving requests.

Why EmDash sites were not affected

EmDash is written in TypeScript and runs on Cloudflare Workers or on Node.js. There is no PHP in it at all, so PHP2Shell does not apply: nothing to patch, nothing to take offline. This site, nesmachny.com, moved from WordPress to EmDash in September 2026. On October 21 we did not have to do anything.

I won't call EmDash invulnerable. Every stack has bugs, Node.js included. The difference is in how a typical site is built:

  • Less to patch. On Cloudflare Workers there is no server of your own; Cloudflare updates the runtime. On your own server you update one Node.js, not PHP with a dozen extensions.
  • Plugins don't get the whole server. A WordPress plugin can read the entire database and file system. An EmDash plugin declares the permissions it needs up front, and on Cloudflare it runs in an isolated worker.
  • No files to include. Many PHP2Shell exploits need a second bug such as a local file inclusion. An EmDash site does not execute files from disk on request the way PHP does.

How the move worked for us, with real numbers on cost and speed, is in our story of leaving WordPress for EmDash.

Should you migrate?

One vulnerability, even a loud one, is not a reason to rush a migration. It is a good moment to count how often you patch PHP, the CMS core and plugins in a year, and who does it.

Moving makes sense if your site is a company website, a blog or a landing page and WordPress maintenance has become a chore. If you run an online store with many integrations, take your time: some WordPress plugins have no EmDash equivalent yet. If you want the move done for you, see our WordPress to EmDash migration service. If your PHP site is staying where it is, a technical SEO and speed fix is the cheaper first step.

Frequently asked questions

Is my WordPress site vulnerable to PHP2Shell?

WordPress itself is not the problem; the PHP it runs on is. If your server runs PHP older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and your distribution has not backported the patch, the site is exposed. Updating WordPress plugins will not help. You need to update PHP itself or ask your host to do it.

How do I check whether my host has patched PHP?

Ask support for the exact PHP version and whether the October 21 patches are included. You can also check yourself: upload a temporary file that calls phpinfo(), read the version number, and delete the file straight away. Hosts that build PHP themselves may show a different version number, so confirm the patch status with them.

Should I take my site offline until PHP is updated?

Sansec says taking a site offline is not necessary, because public exploits do not work against default installations. If you cannot patch quickly, turn off session.upload_progress.enabled and block multipart/form-data requests as a stopgap. European governments went offline as a precaution because the cost of a breach is higher for them.

Does PHP2Shell affect EmDash sites?

No. EmDash is written in TypeScript and runs on Cloudflare Workers or Node.js, and it does not use PHP. The PHP2Shell flaws live in the PHP interpreter, so they do not reach EmDash sites. That does not make EmDash immune to every bug: Node.js and its dependencies still need regular updates.

Sources: CISA, Sansec, Datadog Security Labs, Qualys, watchTowr, Help Net Security.

Sergey Nesmachny

Written by

Sergey Nesmachny

Share: