Guides

Security & Tech

PHP2Shell: Is your TYPO3 or WordPress website affected? What you need to do now

Germany's BSI has issued an orange alert for the PHP vulnerability PHP2Shell. Here's how to check in a few minutes whether your TYPO3, WordPress or Shopware website is affected, and what you need to do now.

  • Published:

    October 21, 2026

  • Updated:

    October 21, 2026

  • 13 min read

    Reading time

YouTube thumbnail: PHP logo with a broken padlock and the question "Websites at risk?!" about the PHP2Shell vulnerability

Key takeaways

  • The vulnerability is in PHP, not in TYPO3 or WordPress. Only a PHP update on the server helps
  • Safe versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 or newer, and the full version number counts
  • PHP 8.1 and older no longer get an official update
  • TYPO3 10 and older only run up to PHP 7.4 and need an upgrade or a relaunch
  • After updating, check whether someone has already broken in

On October 21, 2026, Germany's Federal Office for Information Security (BSI) issued an orange alert because of a vulnerability in PHP. It's called PHP2Shell and affects almost every classic website running on TYPO3, WordPress, Shopware, Joomla or Drupal. In this guide, we explain in plain language what happened, how to check in a few minutes whether your site is affected, and exactly what to do next. You also get two free PDF checklists (in German), one for TYPO3 and one for WordPress. This guide reflects the situation as of the evening of October 21, 2026.

Summary

  • What happened: There are two critical vulnerabilities in the PHP core (CVE-2026-109618 and CVE-2026-109619, each rated 9.2 out of 10). Attackers can use them to run their own code on your server without logging in. Updates have been available since October 21.
  • Who is affected: Every website whose server processes requests with PHP. That means almost all sites running TYPO3, WordPress, Shopware, Joomla or Drupal, whether with a hosting provider, on your own server or in Docker.
  • What you need to do today: Check your PHP version, move to a safe version (8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer), get written confirmation of the patch and check whether someone has already got in.

What is PHP2Shell?

PHP is the programming language that WordPress, TYPO3, Joomla, Drupal, Shopware and many other systems run on. Think of PHP as the engine under the hood. Your CMS is the car on top. Two vulnerabilities have now been found in exactly that engine.

Through these vulnerabilities, an attacker can run their own code on your server. No login, no password, and without you clicking anything. Experts call this remote code execution. On top of that, memory can be read from PHP processes, and it may contain passwords, tokens or API keys from other requests.

The two vulnerabilities in simple terms

  • CVE-2026-109618: PHP runs out of memory while a request is only half prepared. Attackers can exploit this half-finished state.
  • CVE-2026-109619: Leftovers from an earlier request stay stuck in the worker process and are reused by a later request. Experts call this use after free.

The PHP security team rates both vulnerabilities at 9.2 out of 10 (CVSS 4.0), which is critical. The name PHP2Shell is a nod to Log4Shell, one of the biggest security vulnerabilities of 2021.

The vulnerability isn't in your CMS

This is the point many people get wrong: the bug isn't in WordPress, TYPO3 or Shopware, it's in PHP itself. You can click as many updates in your backend as you like. It won't help here. The update has to happen on the server.

Who found it

The bugs were discovered by Wiz Research, Calif and OpenAI Codex Security and fixed together with the PHP team and the Google Gemini team. On test installations of WordPress, Drupal and Joomla, Wiz was able to run code and read passwords and API keys from memory.

Why it's so urgent

BSI orange alert

On October 21, 2026, the BSI issued alert level 3 (orange). That means: extremely high threat, action must be taken immediately. BSI Vice President Thomas Caspers expects the vulnerability to be exploited on a large scale within a few hours. Parts of German states, municipalities, authorities, universities and hospitals took their websites offline as a precaution. The UK's NCSC and CERT-EU also advise temporarily taking offline or isolating systems that can't be patched right away.

Leaked and released a day early

The details were originally due to be published on October 22. But information leaked on October 20. That's why the PHP team brought the updates forward. They have been available since October 21, shortly before 4 pm German time.

First attack attempts

According to CTO Dane Knecht, Cloudflare has already seen first attack attempts. watchTowr reported exploitation attempts via honeypots, and Patchstack reported scans for vulnerable servers. As of October 21, there were no officially confirmed successful break-ins. We wouldn't wait for that, though.

AI makes attacks faster

According to the researchers, the bugs had been in PHP for more than a decade. Exploiting them used to be extremely complicated. Modern AI models lowered the bar so far that working attacks became possible: one researcher in about a week instead of a whole team over months. The BSI says exactly this in its alert: attackers can use AI tools to analyze updates quickly and turn them into attacks. The time between update and attack shrinks to a few hours.

How many servers could be affected

According to a count by Mallory using the server search engine Shodan (as of October 20), around 884,000 reachable servers report a PHP version that no longer receives official support. That's 59 % of about 1.5 million servers with a visible version number. Important: this is a count based on server banners, not a list of confirmed vulnerable systems. According to WordPress.org, 36.4 % of all WordPress sites also run on PHP 8.1 or older.

Am I affected? The 4 scenarios

Every PHP installation that processes web requests is affected: Apache with mod_php (highest risk), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. According to Wiz, at least one of the two vulnerabilities exists in every PHP version since 5.4. What you need to do depends on where your website runs.

Scenario 1: Web hosting package with IONOS, Strato, All-Inkl and the like

Your host installs the PHP update on its servers. Your job: check the PHP version, switch it to 8.3 if it's older, and get written confirmation of the patch.

Scenario 2: Your own server, VPS or Docker

Then it's on you. Today, not next week. Install the updated packages from your Linux distribution or rebuild and roll out your images. Then restart Apache, PHP-FPM and all workers, not just reload them.

Scenario 3: An agency looks after your site

Call them or send an email. Ask for the exact PHP version and get the patch confirmed in writing. You'll find a ready-made template further down.

Scenario 4: Webflow and other systems without your own PHP server

If your site runs on Webflow, there's no PHP server you have to maintain yourself. Hosting, server updates and security are handled by the provider. More on that at the end of this guide.

Which PHP versions are safe?

These versions or newer are safe:

PHP branchSafe from versionNote
PHP 8.58.5.12officially patched
PHP 8.48.4.27officially patched, good target
PHP 8.38.3.36officially patched, good target (8.3.6 is not safe)
PHP 8.28.2.35patched, security support ends on Dec 31, 2026
PHP 7.4, 8.0, 8.1no official releaseEnd of life: source code backports only, ready-made packages only via Linux distributions, LTS vendors or hosts
PHP 7.3 and olderno fixupdate urgently

What matters is the full version number, not just the first digit. PHP 8.3.6 is not safe, 8.3.36 is. Linux distributions sometimes ship the fix in packages with an older version number. In that case, check the changelog: if CVE-2026-109618 and CVE-2026-109619 are mentioned, the fix is included. With shared hosting, your customer account often only shows "8.3" without the exact number behind it. Then you should get the patch confirmed in writing.

Since security support for PHP 8.2 ends on December 31, 2026, we recommend PHP 8.3 or 8.4 as your target.

How to check your PHP version

TYPO3

Log into the backend as an admin and click the system information icon in the top right. It shows the PHP version right away. Alternatively, you'll find it under Admin Tools → Environment → Environment Status. Editors can't see this information. In that case, ask your agency.

Watch out: Below it, you'll often see "Your system is fully functional". That has nothing to do with this vulnerability. A system running PHP 8.3.6 is shown as fully functional there, but it's not safe. That's exactly what makes it dangerous.

WordPress

In the dashboard under Tools → Site Health → Info, in the Server section.

Shopware 6

In the administration under Settings → System → System information. If you can't find a PHP version there, ask your host.

With your host, using IONOS as an example

In your IONOS customer account, go to Menu → Hosting and click Open in the PHP tile. There you'll see which version is set for each domain. For IONOS Managed WordPress, the PHP version is under Settings, at the very bottom in the advanced settings. Use the pencil icon next to it to switch. PHP 8.3 is marked as recommended there, switching is free and can be reversed.

No access to the backend or your hosting account? Then ask your agency or your host directly.

Secure your site step by step

Step 1: Check your PHP version

As described above, in the backend or in your hosting account. Note down the full number and compare it with the table.

Step 2: Switch to PHP 8.3 if you're on 8.1 or older

Please don't click blindly. First, make a full backup of your files and database. Then switch, ideally on a subdomain or staging environment first. IONOS itself recommends this, by the way. Afterwards, test:

  • the homepage and several subpages,
  • the contact form with a test inquiry,
  • the backend login,
  • for a shop, the complete checkout.

If something breaks, most hosts let you switch the version back. On your own server: update packages or images, then restart Apache, PHP-FPM and workers.

Step 3: Get the patch confirmed in writing

With shared hosting, you often only see "8.3". So send your host a short message: has the update to 8.3.36 been installed on my account? And get it in writing. You'll find a matching template in the next section.

Step 4: Check whether someone has already got in

The update closes the door. But if someone got in before and left a back door, it stays open. What exactly to check is described further down in the section on looking for traces.

Step 5: Old TYPO3? Plan an upgrade or relaunch

If your site runs on TYPO3 10 or older, you can't simply raise the PHP version. In that case, plan an upgrade or a relaunch. More on this in the TYPO3 trap below. If you don't want to carry updates and monitoring yourself in the future, take a look at our website maintenance.

Email template for your host or agency

Copy this template, add your name and domain, and send it to your host or agency:

Template to copySubject: PHP2Shell (CVE-2026-109618 / CVE-2026-109619): Please confirm patch status Hi [Name], because of the PHP vulnerability PHP2Shell (BSI orange alert of Oct 21, 2026), I'd like a short written confirmation for my website [domain]: 1. Which PHP version is running exactly (full version number)? 2. Has the update to 8.3.36 been installed on my account (or 8.2.35, 8.4.27, 8.5.12 or newer)? If a distribution package with an older number is in use: does it include the fix for both CVEs? 3. Were Apache or PHP-FPM restarted afterwards? Please confirm this in writing. Thanks! Best regards [Name]

The TYPO3 trap: old versions

Every TYPO3 version only runs on certain PHP versions. This is the trap many older TYPO3 sites are running into right now:

  • TYPO3 12 and 13 run on PHP 8.2 and 8.3. TYPO3 13 requires at least PHP 8.2.
  • TYPO3 11 also runs on 8.2 and 8.3. Check your extensions first, though.
  • TYPO3 10, 9 and older only run up to PHP 7.4.

That means: with TYPO3 10 or older, you can't move PHP to a safe, officially patched version without breaking your website. And for PHP 7.4, the PHP project has no official release, only source code backports. You're then completely dependent on whether your host builds a patch itself.

Honestly: in this case, a quick click won't help anymore. You need a TYPO3 upgrade or a relaunch. And you should tackle that before something happens, not after. What a switch can look like is shown on our page about migrating from TYPO3 to Webflow. If you want to stay on TYPO3, we can support the upgrade through our web development service.

WordPress: what helps and what doesn't

WordPress isn't getting its own update for PHP2Shell, because the vulnerability is in PHP. According to WordPress.org, 36.4 % of WordPress sites run on PHP 8.1 or older, meaning versions without an official security update. For self-managed servers with PHP below 8.2, WordPress.org recommends taking the site offline if necessary.

  • Helps: switching PHP to 8.3 or 8.4. Current WordPress runs on it. Old themes and plugins can cause problems, so make a backup first and ideally test on staging.
  • Doesn't help: security plugins. The attack happens before WordPress even loads.
  • Doesn't help: "fix plugins" that are popping up now. Don't install anything like that.
  • Doesn't help: a plugin's maintenance mode. PHP keeps running. If you need to take the site offline, do it at server level, for example with an .htaccess 503 status or password protection at your host.

Want to stay on WordPress and have it set up properly? Then check out our WordPress agency page.

Check whether someone has already got in

The update closes the vulnerability, but it doesn't remove a back door that was planted before. So after the update, check:

  • Are there admin users you don't recognize?
  • Are there unfamiliar or new PHP files on the server, especially in upload folders such as wp-content/uploads in WordPress or fileadmin and typo3temp in TYPO3?
  • Were theme or template files changed recently without you knowing?
  • Are there new cron jobs on the server?
  • Does your site redirect strangely or are spam pages showing up?

According to Wiz and the PHP team, there are also technical warning signs: frequent HTTP 500 or memory limit errors after unusual uploads, conspicuously large PHPSESSID cookies and PHP processes that restart for no reason.

If you suspect something

Keep the site offline, secure the logs, restore a clean backup from before the attack and change all passwords and API keys. If personal data is affected, a data breach generally has to be reported to the supervisory authority within 72 hours under Art. 33 GDPR. This is not legal advice, so if in doubt, get legal counsel.

What doesn't help

Lots of tips are going around in forums right now. These won't make you safe:

  • Updates in the CMS backend: the vulnerability is in PHP, not in the CMS.
  • Config tricks: settings like memory_limit=-1, session.upload_progress.enabled=0 or blocking upload and multipart requests at the proxy only block individual attack paths, according to the PHP team. They won't make your site safe.
  • Security or "fix" plugins: they only kick in once the CMS loads. By then it's too late.

The only thing that really helps is the PHP update.

Stopgap: Cloudflare

If your site runs behind Cloudflare, you have a buffer: Cloudflare has already enabled web application firewall rules for known attack paths, for all customers, including the free plan. This doesn't replace the update and only works for requests that actually go through Cloudflare. But it buys you time.

Why we recommend Webflow for many companies

We're a branding and web design agency, one of 7 Webflow Premium Partners in Germany, and we don't only build with Webflow but also with WordPress and TYPO3. So we'll be honest: TYPO3 and WordPress aren't bad. But if you host yourself, you're also responsible yourself.

PHP2Shell shows what that means. If you host your website yourself, you have to patch faster than attackers using AI can attack. Hardly any company manages that on the side. That's exactly why we recommend Webflow for most business websites. There's no PHP server you have to maintain. Hosting, server updates and security are handled by Webflow.

So you don't have to install an update at night and hope your site still works afterwards. No plugin that breaks after an update. No server you have to keep an eye on. If you're thinking about switching, you'll find everything about moving from WordPress to Webflow and from TYPO3 to Webflow, plus an overview of all the platforms we work with.

Downloads: checklists for TYPO3 and WordPress

Everything important from this guide is also available as a compact checklist with click paths, test list, email template and trace check. The checklists are in German:

The video for this guide

In the video, we explain in short and plain terms what is behind PHP2Shell, whether your website is affected and what you should do now. The video is in German.

FAQ

What is PHP2Shell?

PHP2Shell is the name for two critical security vulnerabilities in the PHP core (CVE-2026-109618 and CVE-2026-109619), rated 9.2 out of 10 by the PHP security team. Attackers can use them to run their own code on the server without logging in and to read memory. Germany's BSI issued an orange alert on October 21, 2026.

Is an update in the WordPress or TYPO3 backend enough?

No. The vulnerability is in PHP itself, not in the CMS. WordPress and TYPO3 aren't getting their own update for it. Only a PHP update on the server helps, after which Apache or PHP-FPM must be restarted.

Which PHP version is safe?

PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer are safe. The full version number matters: 8.3.6 is not safe, 8.3.36 is. PHP 8.1 and older no longer get an official release.

My host only shows "8.3". Am I safe?

You can't tell from that. With shared hosting, you often only see the version branch. Get written confirmation from your host that the update to 8.3.36 (or a package with the fix for both CVEs) has been installed.

Does a security plugin or maintenance mode help?

No. The attack happens before WordPress or TYPO3 even load. A plugin's maintenance mode doesn't protect you either, because PHP keeps running. You have to take the site offline at server level, for example with an .htaccess 503 or password protection at your host.

What do I do with TYPO3 10 or older?

TYPO3 10, 9 and older only run up to PHP 7.4. For 7.4, the PHP project has no official release, only source code backports. You're then dependent on whether your host builds a patch. In the long run, only a TYPO3 upgrade or a relaunch helps.

Is my Webflow website affected?

Webflow websites don't run on a PHP server that you have to maintain. Hosting, server updates and security are handled by Webflow. So with PHP2Shell, there's nothing for you to patch.

Do I have to report an attack?

If personal data is affected, a data breach generally has to be reported to the competent supervisory authority within 72 hours under Art. 33 GDPR. This is not legal advice, so if in doubt, get legal counsel.

Sources

We can help

You've realized your site is affected and need help? Whether it's the PHP update, a TYPO3 upgrade, a relaunch or a move to Webflow: we'll take care of it at short notice. Book a free initial consultation, request your project directly or write to us via our contact page.

More guides

All guides
Chrome 3D Webwavers WChrome 3D Webwavers W

Contact

Start your next digital chapter

Request a project