Web Apps & MVP

PHP2Shell: What the critical PHP flaw means for your WordPress site

Two critical PHP flaws allow attacks without a login. Who is affected, what to do now, and when moving away from WordPress makes sense.

23 October 2026 · Eddy-Romeo Lackmann

On 21 October 2026, the PHP project fixed two critical security flaws that have become known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). They let attackers run their own code on a web server without logging in. Practically every PHP version since 5.4 is affected, and with it most WordPress sites. If you run a website on WordPress, Joomla, Drupal or another PHP system, check today whether your server has already been updated.

What is PHP2Shell?

PHP2Shell is the name for two bugs in PHP itself, the programming language WordPress runs on. A plugin or theme is not to blame this time.

  • CVE-2026-109618: If PHP runs out of memory while accepting a request, internal data is left half-built. The cleanup that follows still treats it as valid.
  • CVE-2026-109619: Data from one request still points to freed memory after the request ends. The next request handled by the same PHP process can access it.

The PHP project rates both flaws 9.2 out of 10 (CVSS 4.0). According to the PHP security team, every installation that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest with mod_php, because the attack works there before any of the website's code runs.

Which PHP versions are affected?

The fixes are in these versions:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

PHP 7.4, 8.0 and 8.1 no longer get official releases. Because of the severity, the PHP team has published minimal source code fixes, and some Linux distributions ship their own updates. PHP 7.3 and older stay unfixed.

How many servers are affected depends on how you count. One security researcher estimates a good 1.3 million reachable servers; Palo Alto Networks counts over 22.6 million installations that may be vulnerable. According to W3Techs, around 69 percent of all websites with a known server-side language use PHP.

Is it already being exploited?

The situation escalated within a few days:

  • 17 October: Amazon sees a first attack attempt in a trap for attackers (honeypot), four days before disclosure.
  • 20 October: Details leak on social media. The PHP project moves the release forward by a day.
  • 21 October: The updates are released. Security firms such as watchTowr and Cloudflare report first attacks.
  • 22 October: Germany's federal cyber security agency BSI updates its warning. At that point it knows of no successful large-scale exploitation, while Amazon reports broad attacks by several groups.

The Calif research team that analysed the flaws says it was able to take over specific versions of WordPress, Drupal, Joomla and Magento without logging in. We therefore assume that unpatched servers are being attacked.

What you should do now

If your website is with a hosting provider (shared hosting, managed WordPress): ask whether your server already runs one of the fixed versions. You can see your PHP version in WordPress under Tools → Site Health → Info → Server. If it shows a version below 8.2, switch to a current one. Many hosts let you do that in their customer panel.

If you run your own server or container:

  1. List every system with PHP, starting with publicly reachable ones and anything using mod_php.
  2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution's package.
  3. Restart all PHP processes. Running processes keep the old code in memory.
  4. Check whether unknown files have appeared since 17 October, such as PHP files in upload or cache folders.

If you can't update right away, you can reduce the risk temporarily. The PHP project lists memory_limit = -1, a low post_max_size and session.upload_progress.enabled = 0, plus fatal_error_backtraces = 0 on PHP 8.5. These values belong in php.ini or the FPM pool, not in .user.ini. According to the PHP team this is not complete protection; only the update closes the flaws. The US agency CISA recommends taking systems on PHP 8.1 or older offline if they can't be updated.

Why WordPress sites are hit so often

For WordPress site owners, PHP2Shell is the third emergency in a few months:

  • July 2026, wp2shell: A chain of two bugs in WordPress core (CVE-2026-63030 and CVE-2026-60137) made it possible to take over a default installation without a login and without plugins. WordPress released versions 7.0.2 and 6.9.5 on 17 July. Within a day, public attack tools were on GitHub, and CISA reported active attacks.
  • October 2026, Bricksforge: A flaw in this plugin (CVE-2026-85097), rated the maximum 10 out of 10, allowed uploading and running PHP code. It was actively exploited.
  • October 2026, PHP2Shell: this time one level deeper, in PHP itself.

The reason is the architecture. On every page view, the server runs PHP code from the core, the theme and often 20 or more plugins. Each of these layers has to stay up to date, and a single outdated one is enough for an attack.

Does it have to be a migration right away?

Not necessarily. A well-maintained WordPress site with current PHP, few plugins and someone who installs updates promptly can be run securely.

A migration makes more sense if several of these apply:

  • Your site mainly shows content and doesn't need logins or shop features.
  • Nobody is really responsible for updates, or they sit for weeks.
  • You use many plugins, some without knowing what for.
  • Your server still runs PHP 8.1 or older.

The alternative is a statically generated website. Pages are built once and delivered as finished files. No PHP and no database run on the server when someone views a page, so flaws like PHP2Shell or wp2shell have nothing to attack. You still edit content comfortably in a content management system. This website is built that way too: with Astro and the Keystatic CMS, with no PHP on the server.

Sources

As of 23 October 2026. The situation is still developing. The PHP project's and BSI's guidance take precedence.

← All articles

Let’s connect

Affected? Let's talk.

Not sure whether your site is affected, or tired of constant patching after PHP2Shell? We'll look at your site together and tell you honestly whether an update is enough or whether moving to a different stack is worth it.

30 min · free · an honest take on whether it's worth it

What happens3 steps
first call — 30 minfree
  1. You tell us where things get stuck.
  2. We ask questions and look at your workflows.
  3. You get an honest assessment and, if it fits, a suggestion for the next step.
→ Then: a concept with clear effort and benefit
Open source tools we use