secaudit.eu
Incident response

PHP2Shell: what WordPress site owners must do now

PHP2Shell (CVE-2026-109618, CVE-2026-109619) lets attackers run code on unpatched PHP. Check your PHP version, update, restart and watch for signs.

By , AngelForce OÜ 5 min read

Also in: Deutsch Français Español Italiano Polski Português Türkçe

PHP2Shell is a pair of critical vulnerabilities in PHP itself, disclosed on 21 October 2026 and rated CVSS 9.2. On an unpatched PHP runtime, an attacker without an account can run code on the server or read memory that holds passwords, session tokens and API keys. The researchers demonstrated it against current WordPress installations. Updating WordPress, your theme or your plugins does not fix it: the PHP version underneath your site has to be updated.

This guide explains what PHP2Shell is, how to check whether your site is affected, what to ask your host, and what to do if the update cannot happen today.

PHP2Shell in 82 seconds: how to close it in four steps. The video loads from YouTube when you press play.

What PHP2Shell is

The research by Wiz Research, OpenAI Codex Security and Calif found two related classes of memory-safety bugs in the PHP engine:

  • CVE-2026-109618, out-of-memory corruption. The way PHP handles running out of memory can corrupt its state. An attacker can use this to execute code as the PHP web worker, without logging in.
  • CVE-2026-109619, stale global state across requests. Data from one request can survive into the next one. This leads to a use-after-free that can leak worker memory or execute code.

Because the flaw is in PHP, your own code does not need to contain a bug. According to the researchers, even a "Hello World" page on an affected PHP version can be exposed. WordPress, Drupal and Joomla were simply the applications they used to demonstrate unauthenticated remote code execution. The PHP team released fixed versions the same day.

Two consequences matter most for a WordPress site:

  1. Server takeover. Code execution as the PHP worker usually means the attacker can change files, add an administrator, plant a backdoor or reach the database.
  2. Silent data theft. The memory disclosure works without running malicious code, so it can leave few traces. Memory of a busy PHP worker can contain other visitors' passwords and cookies, your database password and API keys.

Is my site affected?

Almost certainly, unless your PHP was updated on or after 21 October 2026. The researchers found affected releases going back to PHP 5.4. These are the first fixed releases per supported branch:

PHP branchVulnerableFirst fixed release
8.2below 8.2.358.2.35
8.3below 8.3.368.3.36
8.4below 8.4.278.4.27
8.5below 8.5.128.5.12

PHP 8.1, 8.0 and every 7.x version are no longer supported by the PHP project and are not in this table. If your site runs one of them, there is no fixed release to install: you need to move to a supported branch.

To see your exact version in WordPress, open Tools → Site Health → Info and expand Server. The line "PHP version" shows the full number, for example 8.3.36. The first two parts (8.3) are not enough: what matters is the last number.

How to fix it

The only complete fix is a patched PHP runtime, followed by a restart.

  1. Update PHP on every runtime. On your own server, install the updated packages from your distribution as soon as they are published, or the official release from php.net. On managed or shared hosting, the host updates PHP; ask them directly whether your plan already runs the fixed release.
  2. Restart PHP. A new PHP package does nothing until the running processes are replaced. Restart PHP-FPM, Apache with mod_php and any long-running PHP workers.
  3. Check the result. Look at Site Health again. The PHP version must now be at or above the fixed release for your branch.
  4. Do not forget the other runtimes. Staging sites, a second PHP version selected in your hosting panel, the PHP used for cron jobs and WP-CLI, and container images all count.

If you use a hosting control panel with a PHP version selector, choosing "8.3" or "8.4" is only safe if the host has already installed the patched build behind that label. Site Health tells you the truth.

If you cannot update today

The researchers list temporary measures. Each one blocks some attack paths, none blocks all of them, and some can affect your site, so test first:

  • fatal_error_backtraces = 0 where your PHP version supports it.
  • Lower post_max_size and max_input_nesting_level as far as your forms and uploads allow, and set session.upload_progress.enabled = 0 if nothing uses upload progress.
  • Recycle PHP-FPM workers more often with a lower pm.max_requests (this costs performance).
  • memory_limit = -1 removes the memory-limit path that some attacks rely on, but hands memory exhaustion to the operating system. Only use it with an operating-system limit such as cgroup v2 memory.max, and never replace it with RLIMIT_AS or RLIMIT_DATA, which the PHP advisory says can trigger the same bug.

Hiding PHP errors (display_errors, error_reporting or @) is not one of these measures: the PHP project says it does not help.

Firewall and CDN providers have published rules for PHP2Shell. They can reduce exposure, but the researchers are clear that a protective rule is not a substitute for updating PHP.

Signs to look for

No single log line proves an attack. The researchers name signals worth investigating: unusually large or malformed PHPSESSID cookies in responses, odd multipart requests followed by memory-limit errors or bursts of HTTP 500 responses, and PHP workers that crash or restart without a reason. Their absence does not prove your site is clean, because the memory disclosure may leave nothing in the WordPress logs.

If you see these signs, treat it as a possible incident. Our guide to a hacked WordPress site helps with the first checks. Because leaked memory can contain secrets, change the database password, the keys and salts in wp-config.php and any API keys after patching. If personal data may have been exposed, the GDPR clock starts: see our 72-hour breach guide.

Where to start

  1. Open Tools → Site Health → Info → Server and write down the exact PHP version of every site you run.
  2. Compare it with the table above. Anything below the fixed release, or on PHP 8.1 or older, needs action today.
  3. Update PHP or ask your host for the patched release, then make sure PHP-FPM or Apache is restarted.
  4. Check Site Health again and keep the screenshot as evidence of the fix.
  5. Review your logs for the signs above and rotate secrets if anything looks wrong.

Sources: php2shell.com, PHP Foundation announcement, Wiz Research.

Check your own site

Security Audit & Compliance is the WordPress plugin from secaudit.eu: it scans for malware, hidden spam, changed core files and vulnerable code, and maps its findings to GDPR Art. 32, NIS2 Art. 21 and the OWASP Top 10.

See what the plugin checks
Melike Görel

Melike Görel writes the secaudit.eu guides on WordPress security and EU compliance for AngelForce OÜ, the Tallinn software company behind secaudit.eu.

Prepared with AI assistance and fact-checked before publication. This article is general information, not legal advice.