WP2Shell vs PHP2Shell: Two Bugs, Two Fixes

Are WP2Shell and PHP2Shell the same thing?

No. They are two different vulnerabilities, disclosed three months apart, in two different pieces of software. The names are close enough that people search for one and find the other, and both can end with an attacker running a “shell” on your server, so the confusion is understandable. But if you treat them as one problem you will fix the wrong thing.

Here is the one-sentence version of each:

• PHP2Shell is a pair of bugs in PHP itself — the language runtime your host installs to run WordPress. It is fixed by updating PHP on the server, which on most sites is your host’s job.
• WP2Shell is a flaw in WordPress code. It is fixed by the ordinary WordPress, plugin and theme updates you already run — your job.

That difference — whose software has the bug, and therefore who patches it — is the whole story. Everything below just fills it in.

PHP2Shell CVEs

CVE-2026-109618 · CVE-2026-109619

PHP2Shell fixed by

Updating PHP (host)

WP2Shell CVEs

CVE-2026-63030 · CVE-2026-60137

WP2Shell fixed by

Updating WordPress (you)

WP2Shell vs PHP2Shell, side by side

If you only read one thing, read this table. A site is only fully covered when both columns are green.

PHP2Shell: a bug in PHP itself

Every WordPress site is a pile of PHP files, and something has to read and run them on each request: the PHP runtime. PHP2Shell is the nickname for two bugs in that runtime, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2 (Critical) by the PHP project. Under the right conditions they let an unauthenticated attacker run code with the privileges of the web server’s PHP worker.

Both are about PHP losing track of its own memory while handling a request:

• CVE-2026-109618 — an out-of-memory condition interrupts PHP while a request is only partly set up, and the clean-up code then trusts data that was never finished.
• CVE-2026-109619 — internal state outlives the memory it points to, so a later request on the same worker can reuse the leftovers. Researchers also showed it can leak chunks of server memory, which may contain passwords, session tokens or API keys.

Because some demonstrated attack paths run before WordPress has loaded a single line (during PHP’s own request parsing), WordPress updates and security plugins cannot fix this one. The PHP project’s guidance is blunt: updating PHP is the only complete fix. There is a full walkthrough in our PHP2Shell and WordPress guide, and a deeper, CVE-by-CVE explainer in CVE-2026-109618 & CVE-2026-109619 explained.

WP2Shell: a bug in WordPress

WP2Shell (tracked as CVE-2026-63030 and CVE-2026-60137) is a separate WordPress-layer vulnerability that surfaced in July 2026, months before PHP2Shell existed. It lives in WordPress code, not in the PHP runtime, which means it behaves like the WordPress vulnerabilities you are used to: it was addressed through the normal update channel.

In practice that means WP2Shell is fixed the boring, familiar way — by keeping WordPress core, your plugins and your themes current. If you have automatic updates enabled, or you have applied updates since July 2026, you are most likely already covered. The reason it keeps coming up now is simply that its name collides with PHP2Shell in search results.

Who fixes each, and how

The fastest way to not waste an afternoon is to route each bug to the right owner.

For the bigger picture on keeping both layers healthy — updates, backups, logins and hosting choices — see our WordPress security guide.

How to check you’re covered for both

For WP2Shell, the check is quick: open Dashboard › Updates and confirm WordPress core, plugins and themes show no pending updates. If they’re current, you’re covered.

For PHP2Shell, answer three questions and the checker below will tell you where you stand. It runs entirely in your browser and sends nothing anywhere.

A stack where PHP2Shell can’t apply

There is a reason PHP2Shell and WP2Shell can be confused in the first place: a classic WordPress site stacks WordPress code on top of a PHP runtime, so a bug in either layer is yours to worry about. Take one layer out of the request path and that whole category of problem goes with it.

That is what Presscomet is: a WordPress-compatible platform with the same wp-admin, block editor, permalinks and REST API, rebuilt to run on Node.js with a single SQLite file and no PHP runtime at all. With no PHP in the picture, PHP2Shell and the entire PHP-runtime class of bugs simply don’t apply.

1. 1

   Step 1: Keep both WordPress layers patched today

   Update WordPress and plugins for WP2Shell, and confirm your host patched PHP for PHP2Shell. That covers the live risk right now.
2. 2

   Step 2: Decide who owns each layer going forward

   Write down who patches PHP and who patches WordPress on your site. The sites that came through October calmly were the ones that already knew.
3. 3

   Step 3: Consider taking PHP out of the path

   If your site is mostly content, a PHP-free stack means PHP-runtime bugs stop being your problem entirely.

Curious whether it fits your site? Check your site with the migration tool — it only reads your public pages and lists what would move over, and it never changes anything on your current host.