PHP2Shell FAQ: your questions answered (2026)

PHP2Shell generated a lot of questions in a very short time, and a lot of confusing, contradictory answers along with them. This page collects the ones people actually search for and answers each in a few plain sentences. For the full story — how the flaw works, how to patch it on every kind of hosting, and how to tell if you were hacked — read the main PHP2Shell and WordPress guide. For everything beyond this one flaw, see our WordPress security guide.

CVE IDs

CVE-2026-109618 · CVE-2026-109619

Severity

Critical · CVSS v4.0 9.2

Login needed?

No (unauthenticated)

Fixed in

8.5.12 · 8.4.27 · 8.3.36 · 8.2.35

Released

21 October 2026

CISA KEV

Not listed (as of 24 Oct)

The quickest way to find out where you stand is the checker. It asks three questions, runs entirely in your browser, and sends nothing anywhere:

The basics

What is PHP2Shell?

PHP2Shell is the nickname for two critical vulnerabilities in the PHP runtime — the program on your server that reads and runs PHP code on every page view — tracked as CVE-2026-109618 and CVE-2026-109619. Under the right conditions they let an attacker run code on any server that uses PHP to answer web requests, without logging in. It’s a bug in PHP itself, not in WordPress, a plugin or a theme. The PHP project released fixes on 21 October 2026.

What are the two CVEs?

CVE-2026-109618 is an out-of-memory corruption bug: when PHP runs out of memory part-way through setting up a request, its cleanup code trusts data that was never finished. CVE-2026-109619 is a “stale state” bug: internal state outlives the memory it points to, so a later request handled by the same PHP worker can reuse the leftovers — which can also leak chunks of server memory containing passwords, session tokens or API keys. Both are rated CVSS v4.0 9.2.

How serious is PHP2Shell?

Very. Both CVEs are Critical at CVSS 9.2, the attack needs no login and no user interaction, and success can mean remote code execution with the privileges of the web-server process. The official score flags them as high-complexity because reliable exploitation depends on things like memory layout and which worker handles a given request. In practice that slows attackers down rather than stopping them — they can simply send many attempts — which is why the PHP project says plainly that updating is the only complete fix.

Is PHP2Shell the same as WP2Shell?

No. WP2Shell was a separate WordPress flaw from July 2026 that normal WordPress updates fixed. PHP2Shell is in the PHP runtime and needs a PHP update. The names are almost identical, but the fix is completely different — one is a WordPress update, the other is a server-level PHP update.

Does it affect WordPress?

Does PHP2Shell affect WordPress?

Yes — indirectly, but universally. WordPress is written in PHP, so every self-hosted WordPress site runs on a PHP runtime that was affected until the host updated it. The bug isn’t in WordPress code, but WordPress sites are among the most exposed targets simply because there are so many of them, and so many run on older PHP that is slower to patch.

Is my WordPress site affected by PHP2Shell?

If it’s self-hosted and runs on PHP that answers web requests — which is every normal install — it was affected until PHP was updated on the server. Every common setup is in scope: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed and FrankenPHP, with Apache mod_php rated the highest risk. The checker above tells you whether you still are.

Do I need to update WordPress for PHP2Shell?

No. Updating WordPress will not fix PHP2Shell, because the flaw is one layer below WordPress, in PHP. Keeping WordPress, plugins and themes current is still good practice — and fixes plenty of other problems — but the fix for this one is a PHP update or a patched PHP build from your host. There is no WordPress core release for it.

Will updating my plugins or a security plugin help?

Not for this. Plugin and theme updates don’t touch the PHP runtime, and a WordPress security plugin runs inside PHP after the request has been parsed — but the most dangerous PHP2Shell attack path can trigger before WordPress loads a single line. A CDN or web application firewall in front of the server can filter some attempts, but it isn’t a fix either (more on that below).

Checking and patching

How do I check if I’m affected?

Find the PHP version actually serving your site in wp-admin under Tools › Site Health › Info › Server, or in your hosting panel, and compare it with the fixed releases. If you’re on 7.4, 8.0 or 8.1 you need a vendor-patched build. Our step-by-step guide to checking and updating your PHP version covers every method, including the command-line checks for your own server.

Is PHP2Shell patched, and who patches it?

Yes, fixes exist. On managed hosting, your host patches the PHP runtime for you — most major hosts did so within about a day. On a VPS or dedicated server, you install the updated PHP packages and restart PHP yourself. The fixed upstream releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (21 October 2026). Not sure whether your host has done it? Our what to ask your host guide has a copy-paste email.

My host shows an older version but says I’m patched — what gives?

That’s the backport number trap, and both can be true. Linux distributions and some hosts backport security fixes without changing the version number, so a lower number doesn’t always mean unpatched. Ubuntu 24.04’s patched package still reports 8.3.6, and one site was seen protected while still showing 8.4.26. The only reliable confirmation is your host stating, in writing and with a date, that both CVEs are fixed on your server.

What about end-of-life PHP versions?

PHP 7.4, 8.0 and 8.1 are end of life, so the PHP project shipped source-only backports for PHP2Shell rather than official binary releases — you depend on your distro or host building a package, and anything older than 7.4 got no upstream fix at all. That’s why the smart move is to upgrade to a supported branch. Our PHP 8.1 end-of-life guide explains the support windows and how to move to 8.3 or 8.4 safely.

Exploitation and risk

Can PHP2Shell be exploited?

Yes in principle: it allows unauthenticated remote code execution, and researchers demonstrated several working techniques, including unauthenticated disclosure of PHP worker memory. Reliable exploitation is genuinely difficult because it depends on server conditions, and as of 24 October 2026 some researchers reported that the proof-of-concepts circulating publicly hadn’t achieved code execution. None of that is a reason to wait — treat it as exploitable and patch.

Has PHP2Shell been exploited in the wild?

Attempts, clearly yes; confirmed break-ins, not publicly. Amazon logged an attempt on 17 October 2026 (four days before patches), Cloudflare reported attempts climbing into the millions after disclosure, and watchTowr observed attempts via honeypots. HKCERT said both CVEs were being exploited in the wild and NCSC-NL was investigating first signs of successful misuse. As of 24 October, no successful compromise had been publicly confirmed in the sources we reviewed. Reports conflict, so the honest summary is: actively targeted, no confirmed success yet.

Is PHP2Shell in the CISA KEV catalog?

Not as of 24 October 2026. Neither CVE had been added to CISA’s Known Exploited Vulnerabilities catalog, and CISA said it hadn’t observed exploitation at the time of its publication — though researchers noted that reflects CISA’s own visibility, not proof that attempts aren’t happening. CISA still urged immediate updates. KEV status can change, so check the catalog directly.

If you can’t patch yet

What do I do if I can’t patch right away?

Reach for the PHP project’s temporary settings — disable session.upload_progress, set memory_limit = -1 administratively to block the out-of-memory trigger (restore a finite limit once patched), and on PHP 8.5 set fatal_error_backtraces = 0. Put a CDN/WAF in front so attempts don’t reach your origin directly, and restrict access. For systems that genuinely can’t be patched, government agencies recommended taking them offline or behind network-level authentication. These are stopgaps measured in hours, not a fix.

Is a WAF or firewall enough on its own?

No. A web application firewall or CDN rule set helps — Cloudflare, Imperva and others deployed PHP2Shell rules — but only if all traffic passes through it and your origin server isn’t reachable directly. In-process protections such as RASP or plugin firewalls may not stop the Apache mod_php path, which can fire before application code runs. A WAF buys time; updating PHP is the fix.

How Presscomet relates

Presscomet is a WordPress-compatible CMS that runs the same wp-admin, block editor, permalinks and REST API on Node.js with a single SQLite file — and no PHP runtime. Because PHP isn’t there, PHP2Shell and the entire PHP-runtime class of vulnerabilities simply don’t apply to it.

If a stack where PHP flaws aren’t your problem sounds appealing, check your site against Presscomet — the migration only reads your public site and lists what would move over, so trying it changes nothing on your server. Still working through PHP2Shell itself? Go back to the full PHP2Shell and WordPress guide.