Skip to content
presscomet
Security

PHP2Shell and WordPress: are you affected, and how do you fix it?

Two critical bugs in PHP itself put almost every WordPress site on an affected runtime until the host patches it. Here’s what happened in plain English, a checker that tells you whether you’re affected, and step-by-step fixes for every kind of hosting.

By the Presscomet teamPublished 16 min read

On this page
  1. What happened
  2. Timeline
  3. Am I affected?
  4. Check your PHP version
  5. How to patch
  6. Can’t patch yet?
  7. Was I hacked?
  8. Cleanup steps
  9. Prevent the next one

What happened, in plain English

Your WordPress site is a pile of PHP files. Something has to read those files and run them every time a visitor loads a page: that something is the PHP runtime, a program your hosting company installs on the server. PHP2Shell is a pair of bugs in that program, not in WordPress.

A useful way to picture it: WordPress, your theme and your plugins are the furniture in your flat. PHP is the building’s front door. You can fit the best locks money can buy to your own door (security plugins, strong passwords, two-factor login) and it won’t matter if the front door of the building can be opened by anyone who knows the trick. Fixing the front door is the landlord’s job, which on most WordPress sites means your host.

The two bugs have similar shapes. Both are about PHP losing track of its own memory while it handles a web request:

  • CVE-2026-109618 happens when PHP runs out of memory at exactly the wrong moment while it is still setting up a request. The clean-up code then trusts data that was never finished, and an attacker who shapes that data carefully can turn it into code execution.
  • CVE-2026-109619 is a “stale state” bug: a piece of internal state outlives the memory it points to, so the next request handled by the same PHP worker can read or reuse leftovers. Besides code execution, researchers showed it could leak chunks of the server’s memory — which can contain passwords, session tokens and API keys.

Several of the demonstrated attack paths go through PHP’s file-upload handling (the “session upload progress” feature), which runs while PHP is still reading the request, before WordPress has loaded a single line. That is why WordPress updates and security plugins can’t fix this one.

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 23 Oct)

Why “high complexity” doesn’t mean “safe”

The official score marks both bugs as hard to exploit reliably, because success depends on things like how memory is laid out and which worker handles which request. In practice that slows attackers down rather than stopping them: they can simply send many attempts. The PHP project’s guidance is blunt: updating is the only complete fix.

Timeline

The disclosure didn’t go to plan. Details leaked a day before the coordinated release, and attack attempts started even earlier.

  1. Aug 2026

    Bugs reported to PHP

    Researchers from Wiz, Calif (working with OpenAI) and Quarkslab report the issues. The PHP security team receives the reports from 11 August and starts a coordinated fix with Linux distributions.

  2. 17 Oct 2026

    First attempt seen

    Amazon’s threat intelligence team records an exploitation attempt against its sensors while the bugs are still under embargo.

  3. 20 Oct 2026

    Details leak; PHP announces an emergency release

    Information spreads publicly ahead of the planned disclosure. PHP pre-announces a critical security release for 14:00 UTC the next day.

  4. 21 Oct 2026

    Fixes released

    PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 ship, plus source-only backports for 7.4, 8.0 and 8.1. Distributions (Debian, Ubuntu, Red Hat and others) and control panels (cPanel, Plesk, DirectAdmin) publish patched packages over the following hours.

  5. 21–22 Oct 2026

    Mass scanning

    Cloudflare reports attempts climbing from thousands to millions after the announcement. Managed WordPress hosts roll out firewall rules and patched PHP.

  6. 23 Oct 2026

    Where things stand

    No successful compromise has been publicly confirmed, and neither CVE is in CISA’s Known Exploited Vulnerabilities catalog. Unpatched servers remain the target.

Am I affected?

If your WordPress site runs on PHP that answers web requests — which is every self-hosted WordPress site — it was on an affected runtime until your host or you updated PHP. Every common setup is in scope: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed and FrankenPHP. The PHP project rates Apache mod_php as the riskiest, because the demonstrated attack there needs nothing from your site at all.

Answer three questions and the checker will tell you where you stand. It runs entirely in your browser.

Interactive checker

Am I affected by PHP2Shell?

Runs in your browser · nothing is sent

  1. PHP version
  2. Server API
  3. Hosting
  4. Verdict

Find it in wp-admin under Tools › Site Health › Info › Server. Copy the whole number, e.g. 8.3.14.

Try:

Fixed versions at a glance

PHP branchVulnerableFixed
8.5below 8.5.128.5.12
8.4below 8.4.278.4.27
8.3below 8.3.368.3.36
8.2below 8.2.358.2.35 (end of life 31 Dec 2026)
8.1 · 8.0 · 7.4allOnly via a patched build from your host or distro (source backports exist)
7.3 and olderall (believed back to 5.4)No upstream fix — upgrade PHP

A low version number isn’t always bad news

Linux distributions often fix security bugs without bumping PHP’s version. Ubuntu 24.04’s patched package still reports 8.3.6 (build 8.3.6-0ubuntu0.24.04.13), and Plesk’s fixed 7.4/8.0/8.1 builds keep their numbers but carry an October 21 build date. On a host that does this, the only reliable answer is the host’s own confirmation.

How to check your PHP version

Pick whichever is easiest. The first one works on every WordPress site, and it shows the PHP that actually serves your pages — which is the one that matters.

  1. Log in to wp-admin and open Tools › Site Health ①.
  2. Click the Info tab ②.
  3. Expand the Server panel and read PHP version ③.
  4. Note PHP SAPI ④ too: “apache2handler” means mod_php; “fpm-fcgi” means PHP-FPM; “litespeed” means LiteSpeed.
yoursite.com/wp-admin/site-health.php?tab=debug

Site Health

StatusInfo

Server ▴

Server architectureLinux 6.8.0 x86_64
Web servernginx/1.26.2
PHP version8.3.14 (Supports 64bit values)
PHP SAPIfpm-fcgi
PHP max input variables1000
PHP time limit30
PHP memory limit256M

Other panels: WordPress, Directories and Sizes, Drop-ins, Active Plugins, Database…

Tools › Site Health › Info › Server. Illustration — your values will differ.

Need more detail, such as how to switch versions safely? See how to check and update your PHP version in WordPress.

How to patch PHP2Shell

Pick your hosting type. Whichever it is, the job has two halves: get a fixed PHP build, then restart PHP so the running workers actually use it. Take a backup first if your host doesn’t do it automatically.

You don’t control PHP here; your host does. Most major managed hosts reported patching or mitigating within about a day of the release, but status varied (some deployed firewall rules first, one disabled the affected PHP feature rather than patching).

  1. Check your host’s status page or security blog for a PHP2Shell notice.
  2. Ask support to confirm, in writing, that PHP itself was updated for CVE-2026-109618 and CVE-2026-109619 on your site’s server, and when PHP was restarted.
  3. “We added firewall rules” is a stopgap, not an answer. Ask when the patched PHP will be live.

Copy our email template →

Don’t skip the restart

PHP-FPM, Apache and LiteSpeed keep the old PHP loaded until their workers restart. After any update, restart PHP (or ask your host to), then reload Tools › Site Health › Info and confirm the version changed.

Can’t patch yet? Stopgaps that help (a bit)

The PHP project published temporary settings that close the confirmed attack paths. They are incomplete by the project’s own description, so treat them as hours-long measures, not a fix. They go in php.ini, the PHP-FPM pool or the server config — not in .user.ini or a plugin — and need a PHP restart.

php.ini / FPM pool — temporary only
# Blocks the session upload-progress path (CVE-2026-109619)session.upload_progress.enabled = 0# PHP 8.5 only: blocks the fatal-error backtrace pathfatal_error_backtraces = 0# Blocks the out-of-memory trigger (CVE-2026-109618). Restore a finite limit once patched!memory_limit = -1
  • Put a CDN/WAF in front. Cloudflare and others deployed rules for PHP2Shell traffic. It only helps if traffic actually passes through them and your origin isn’t reachable directly.
  • Restrict access. For sites that can’t be patched quickly, government agencies recommended taking them offline or behind a login at the network level. Maintenance-mode plugins don’t count: they run inside PHP.
  • Don’t disable file uploads on a WordPress site unless you can live without the media library; that mitigation is meant for apps that never accept uploads.

How to tell if you were hacked

Patching closes the door; it doesn’t evict anyone who already got in. If your site was online on an unpatched PHP between 17 October (the first attempt on record) and the moment you patched, go through this list. Tick items as you check them, and press Found this if you see the warning sign.

Interactive checklist

PHP2Shell warning signs

0/12

checked

In WordPress
On the server
In the logs

Ticks are saved in this browser only, so you can come back later.

Quick checks over SSH (run from the WordPress root)
# PHP files where only media should be$ find wp-content/uploads -type f -name '*.php'# PHP files modified since the first recorded attempt$ find . -type f -name '*.php' -newermt '2026-10-17' -not -path './wp-content/cache/*'# Must-use plugins$ ls -la wp-content/mu-plugins# Administrators and when they were created (WP-CLI)$ wp user list --role=administrator --fields=ID,user_login,user_email,user_registered# Core files that differ from the official release$ wp core verify-checksums

If you find something: cleanup steps

Don’t panic, and don’t start deleting files at random — you can destroy the evidence you need to find out how far it went. Work in this order. The full version, with more detail for each step, is our WordPress hacked recovery checklist.

  1. Step 1: Patch PHP first

    Otherwise whatever got in once can get in again the moment you finish cleaning.

  2. Step 2: Contain and preserve

    Put the site behind maintenance at the server or CDN level, or take it offline. Snapshot the server (files, database and logs) before you change anything.

  3. Step 3: Restore from a clean backup

    Choose one from before your exposure window — before 17 October at the latest, older if you’re unsure. Then re-apply content changes made since by hand. Ask your host; many keep 14–30 days of backups.

  4. Step 4: No clean backup? Rebuild from trusted sources

    Reinstall WordPress core (wp core download --force --skip-content), reinstall every plugin and theme from the official source, delete PHP files in uploads, and inspect wp-config.php, .htaccess, .user.ini and mu-plugins by eye.

  5. Step 5: Rotate every secret

    Because PHP2Shell can leak server memory, assume credentials in memory were exposed: all admin passwords, new salts in wp-config.php, the database password, SFTP/SSH and hosting logins, and API keys for SMTP, payment and analytics services.

  6. Step 6: Remove unknown users and app passwords

    Delete accounts and application passwords you can’t vouch for, and reassign their content to a real user.

  7. Step 7: Check how Google sees you

    Fix anything listed in Search Console › Security issues, then request a review. Remove spam URLs and let them 404 or 410.

  8. Step 8: Tell people if you need to

    If personal data (customers, members, form entries) could have been accessed, you may have legal notification duties depending on where you and your users are. Get advice early.

How to avoid the next PHP2Shell

PHP2Shell won’t be the last runtime bug. The sites that came through it calmly had a few things in common:

  • They knew who patches PHP. On managed hosting it’s the host; on a VPS it’s you. Write that down, with a phone number.
  • They were on a supported PHP branch. Sites on 8.3 or 8.4 got a normal update. Sites on 7.4 or 8.1 had to wait for a backport or rush an upgrade. PHP 8.2 leaves support on 31 December 2026.
  • They had automatic security updates and restarts on their own servers (for example unattended-upgrades plus a restart of PHP-FPM).
  • They had a CDN/WAF in front, which filtered a lot of the early noise while the patch rolled out.
  • They had off-server, tested backups from well before the incident.

Or take PHP out of the request path entirely

There’s a more structural option. Most WordPress sites are content sites: pages change a few times a week and are read thousands of times a day. Running PHP on every one of those requests means every PHP bug is your problem. Two ways to change that:

  • Serve a static copy. Static-export tools turn a WordPress site into plain HTML files hosted on a CDN. The public site has no PHP at all; you keep WordPress private for editing (and still patch it, but it’s no longer exposed to the internet).
  • Run a WordPress-compatible stack that has no PHP. That’s what Presscomet is: the same wp-admin, block editor, URLs and REST API, rebuilt to run on Node.js with a single SQLite file. Your content and settings move over with a one-click migration.

What Presscomet does — and doesn’t — change

With no PHP runtime, PHP2Shell and every other PHP-runtime bug simply don’t apply, and public pages are served from a static cache, so most requests never reach application code at all. It is not “unhackable”: Presscomet has its own software to keep updated (Node.js, its libraries and the server it runs on), its own login to protect, and those will have their own advisories some day. It also doesn’t run PHP plugins: the common ones (SEO, forms, SMTP, redirects, security, custom fields and more) are built in, but WooCommerce stores aren’t supported. Compare the details on Presscomet vs WordPress.

If you’re curious, check your site — it reads your public site and lists what would move over, and it never changes anything on your server. Or have us run it for you on managed Presscomet hosting. Read more about the approach in Can you run WordPress without PHP? and our WordPress security guide.

Sources

Facts checked against these sources on October 23, 2026. Things change quickly; the vendor advisory always wins.

  1. [1]PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 security releases — PHP.net
  2. [2]GHSA-w8hw-w9fx-j79w (CVE-2026-109618) — php-src on GitHub
  3. [3]GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) — php-src on GitHub
  4. [4]CVE-2026-109618 — NIST NVD
  5. [5]CVE-2026-109619 — NIST NVD
  6. [6]PHP2Shell advisory (detection and interim mitigations) — Sophos
  7. [7]PHP2Shell FAQ — watchTowr
  8. [8]Two critical PHP flaws: find, mitigate and patch PHP2Shell — Qualys
  9. [9]PHP2Shell: when PHP runs out of memory at the wrong moment — Imperva
  10. [10]PHP2Shell exploitation started days before patches — SecurityWeek
  11. [11]AL26-026 Critical vulnerabilities impacting PHP — Canadian Centre for Cyber Security
  12. [12]Critical vulnerabilities in PHP (PHP2Shell) — Cyber Security Agency of Singapore
  13. [13]PHP2Shell fixes by distro, control panel and PHP version — Digital Applied
  14. [14]USN-8948-1: PHP vulnerabilities — Ubuntu
  15. [15]Debian security tracker: CVE-2026-109618 — Debian
  16. [16]Known Exploited Vulnerabilities catalog — CISA

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name for two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 under CVSS v4.0. Under the right conditions they let an unauthenticated attacker run code on a server that uses PHP to answer web requests. The PHP project released fixes on 21 October 2026.

Will updating WordPress fix PHP2Shell?

No. The flaws are in PHP, the language WordPress runs on, not in WordPress core, plugins or themes. Updating WordPress is still good practice, but only updating PHP (or getting a patched build from your host) fixes PHP2Shell.

Can Wordfence or another security plugin protect me?

Not reliably. WordPress security plugins run inside PHP after the request has been parsed, and the most dangerous attack path can trigger before WordPress loads at all. A CDN or web application firewall in front of the server (such as Cloudflare) can filter some attempts and buy time, but it is not a fix.

Which PHP versions are fixed?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released 21 October 2026. PHP 7.4, 8.0 and 8.1 received source-only backports, so you need a patched build from your host or Linux distribution. Versions older than 7.4 got no upstream fix and should be upgraded.

My host shows an older PHP version but says I'm patched. Who is right?

Possibly both. Linux distributions and some hosts backport security fixes without changing the version number; Ubuntu 24.04’s patched package still reports PHP 8.3.6, for example. Ask your host which advisory or build they applied and when PHP was restarted.

Has PHP2Shell been exploited in the wild?

Attempts, yes: Amazon reported an attempt on 17 October 2026 and Cloudflare reported millions of attempts after disclosure. As of 23 October no successful compromise had been publicly confirmed, and some researchers said circulating proof-of-concepts did not achieve code execution. Treat it as actively targeted.

Is PHP2Shell in the CISA Known Exploited Vulnerabilities catalog?

Not as of 23 October 2026. CISA urged organisations to update PHP immediately, but neither CVE had been added to the KEV catalog when this guide was last checked.

Is PHP2Shell the same as WP2Shell?

No. WP2Shell was a separate WordPress vulnerability from July 2026 that normal WordPress updates fixed. PHP2Shell is in PHP itself and needs a PHP update.

Do I need to restart anything after updating PHP?

Yes. PHP-FPM, Apache and LiteSpeed keep the old code in memory until their workers restart. After updating, restart the PHP service (or ask your host to), then confirm the new version in Tools › Site Health › Info › Server.

Is Presscomet affected by PHP2Shell?

No. Presscomet runs the WordPress admin and sites on Node.js without a PHP runtime, so PHP2Shell and other PHP-runtime bugs don't apply. It has its own software to keep updated (Node.js, its dependencies and the server it runs on), so it is not immune to vulnerabilities in general.

Run WordPress without a PHP runtime to patch.

Presscomet keeps your wp-admin, editor, URLs and content, and serves pages without PHP or MySQL. Check your site for free, then migrate in one click — your old site is only ever read.

Check my site

Keep reading