Aktuell

PHP2Shell: Welche PHP-Version zu WordPress, TYPO3, Drupal und Joomla passt – und in welcher Reihenfolge Sie aktualisieren

Kompatibilitätsmatrix zu PHP2Shell: Welche WordPress-, TYPO3-, Drupal- und Joomla-Version mit welchem PHP läuft und wie Admins jetzt in sieben Schritten aktualisieren.

23. Oktober 2026

Security
Updates
Server

Seit dem 21. Oktober 2026 liegen die Korrekturen für PHP2Shell (CVE-2026-109618 und CVE-2026-109619) vor: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das PHP-Team nennt das Update als einzige vollständige Lösung; das BSI stuft die Lage in seiner Warnung BITS-H Nr. 2026-297981-1032 mit „3 / Orange“ ein. Für Betreiber von Content-Management-Systemen stellt sich damit eine Frage, die in den Erstmeldungen kaum vorkam: Wer noch auf PHP 8.1 oder älter steht, bekommt keine neue Version von php.net – und muss gleichzeitig prüfen, ob sein CMS die nächste PHP-Generation überhaupt verträgt.

Dieser Beitrag ergänzt unsere beiden bisherigen Artikel zu PHP2Shell: Wer kümmert sich eigentlich um das PHP auf Ihrer Webseite? und die laufend aktualisierte PHP2Shell-Statusübersicht.

Was die Lücken mit dem CMS zu tun haben – und was nicht

Beide Schwachstellen liegen im PHP-Kern, konkret in der Behandlung von Speichererschöpfung und veraltetem internen Zustand nach einem Abbruch. Ein Angreifer braucht weder ein Konto noch eine verwundbare Anwendung; CrowdStrike beschreibt eine einzelne anonyme POST-Anfrage als ausreichend bei Apache mit mod_php. Ein sauber gepflegtes WordPress ist deshalb genauso betroffen wie ein vernachlässigtes – Sansec weist nach, dass aktuelle Stände von WordPress 7.1.2, Drupal 11.4.3 und Joomla 6.1.4 angreifbar sind, solange das darunterliegende PHP nicht aktualisiert ist. Umgekehrt gilt: Kein CMS-Update der Welt schließt die Lücke. Es geht ausschließlich um die PHP-Laufzeit.

Übergangsmaßnahme ist kein Ersatz

Die Einstellung session.upload_progress.enabled = 0 blockiert nach Angaben von Tanium nur einen der demonstrierten Pfade für CVE-2026-109619 und hilft gegen CVE-2026-109618 nicht. Das PHP-Team nennt ausdrücklich keine vollständige Mitigation außer dem Update.

Kompatibilitätsmatrix: CMS-Version und PHP-Version

CMS	Version	Unterstütztes PHP	Status
WordPress	7.0 / 7.1	7.4 bis 8.5 (empfohlen 8.3+)	aktuell; 7.0 vom 20.05.2026 hat PHP 7.2/7.3 fallen gelassen
TYPO3	12.4 LTS	8.1 bis 8.4 (8.4 ab 12.4.24)	Support am 30.04.2026 ausgelaufen, nur noch kostenpflichtiges ELTS
TYPO3	13.4 LTS	8.2 bis 8.4	aktuell, Sicherheitsupdates laut Roadmap bis Oktober 2027
TYPO3	14 LTS	8.2 bis 8.5	aktuell seit April 2026
Drupal	10.4 bis 10.6	8.1 bis 8.4 (10.6 empfiehlt 8.4)	10.6 bis Dezember 2026, dann Ende von Drupal 10
Drupal	11.1 / 11.2	8.3 bis 8.4	ältere 11er-Zweige
Drupal	11.3 / 11.4	8.3 bis 8.5	aktuell; Umstieg von 10.6 nur auf 11.3 oder höher
Drupal	12.0	nur 8.5	neue Hauptversion
Joomla	5.4	ab 8.1 (empfohlen 8.3)	letzte 5er-Linie
Joomla	6.x	ab 8.3 (empfohlen 8.4)	aktuell seit 14.10.2025

Dazu die PHP-Seite der Rechnung: PHP 8.1 bekommt seit dem 31.12.2025 keine Sicherheitsupdates mehr, PHP 8.2 endet am 31.12.2026, PHP 8.3 läuft bis Ende 2027 und PHP 8.4 bis Ende 2028.

Schnittpunkt

PHP 8.3

Wird von allen aktuell gepflegten Linien aller vier Systeme getragen und hat noch gut ein Jahr Sicherheitsunterstützung. Die sichere Brücke.

Empfehlung

PHP 8.4

Überall dort die bessere Wahl, wo Erweiterungen und Themes es hergeben – Sicherheitsupdates bis Ende 2028.

Nur Zwischenschritt

PHP 8.2

Läuft am 31.12.2026 selbst aus. Wer heute dorthin wechselt, steht in zwei Monaten erneut vor derselben Frage.

Was Administratoren jetzt in welcher Reihenfolge tun sollten

Bestand aufnehmen, pro Host und pro Pool. php -v zeigt die Kommandozeilen-Version, nicht zwingend die des Webservers. Entscheidend ist, was in den PHP-FPM-Pools oder in mod_php läuft – bei Shared Hosting der PHP-Selektor des Hosters. Auch vergessene Installationen zählen: Roundcube, phpMyAdmin, Nextcloud, Ticketsysteme.
PHP 8.2 bis 8.5: sofort patchen, ohne Kompatibilitätsrisiko. Der Sprung von 8.3.35 auf 8.3.36 ändert nichts am Verhalten des CMS. Debian 13 liefert 8.4.27-1~deb13u1, Debian 12 8.2.35-1~deb12u1. Danach php-fpm beziehungsweise Apache neu starten und die Seite funktional prüfen.
PHP 8.1, 8.0 oder 7.4: Vendor-Backport einspielen – und das Enddatum des Zweigs trotzdem ernst nehmen. php.net liefert keine Pakete, das Sicherheitsteam hat nur minimale Quellcode-Backports veröffentlicht. Ubuntu 22.04 patcht php8.1 (8.1.2-1ubuntu2.28, USN-8948-1), Red Hat den php:7.4-Stream auf RHEL 8 (7.4.33-8, RHSA-2026:87080) und das Standard-PHP 8.0 auf RHEL 9 (RHSA-2026:87151). AlmaLinux hat sämtliche Streams nachgezogen, Remi und packages.sury.org liefern Backports für 7.4 bis 8.1. Der Backport schließt PHP2Shell und sonst nichts – die nächste Lücke in einem EOL-Zweig wird nicht mehr bedient.
Zielversion nach der Matrix wählen, dann erst CMS und Erweiterungen auf Stand bringen, dann PHP anheben. WordPress.org empfiehlt ausdrücklich diese Reihenfolge: Core, Plugins, Themes aktualisieren, Kompatibilität gegen die Zielversion prüfen (etwa mit dem PHP Compatibility Checker), erst dann umschalten. Ein Staging-System ist dafür Pflicht, keine Kür.
Henne-Ei-Fälle sauber auflösen. Wer TYPO3 12.4 auf PHP 8.1 betreibt, kann nicht direkt auf v13 wechseln, weil v13 PHP 8.2 voraussetzt. Der Weg: innerhalb von v12.4 auf PHP 8.3 oder 8.4 heben (beides wird getragen), dann Core-Upgrade auf 13.4 oder 14. Gleiches Muster bei Drupal 10.6 auf 8.1: erst PHP 8.3/8.4, dann 11.3 oder höher. Bei Joomla 5.4: erst PHP 8.3, dann Joomla 6.
Hoster und Dienstleister schriftlich fragen, welche PHP-Version sie eingestellt haben – und ob sie gepatcht ist. Bei Managed-Hosting ist das die Gegenseite, die handeln muss. Eine Antwort „wir sind auf PHP 8.1“ ist ohne Changelog-Nachweis keine Entwarnung.
Nach dem Update auf Fehlermeldungen achten. PHP-Startwarnungen oder 502-Fehler nach dem Neustart sind in der Regel Konfigurationsprobleme, kein Angriff – aber sie gehören protokolliert, auch als Nachweis für NIS2-pflichtige Einrichtungen.

Nachweis bei Backports: php -v zeigt weiter die alte Nummer

Nach einem Vendor-Backport bleibt die Versionsnummer unverändert. Ob die Korrektur enthalten ist, steht nur im Paket-Changelog.

Debian / Ubuntu (Versionsnummer anpassen)

zgrep CVE-2026-109618 /usr/share/doc/php8.1-common/changelog.Debian.gz

RHEL / AlmaLinux / Rocky Linux

rpm -q --changelog php-common | grep CVE-2026-109618

Welches PHP der Webserver tatsächlich nutzt (Debian/Ubuntu)

systemctl list-units 'php*-fpm*' --no-pager
apachectl -M 2>/dev/null | grep -i php

Einordnung

Drei Punkte nehmen wir daraus mit. Erstens: Die PHP-Version war in vielen Projekten ein Detail, das beim Launch festgelegt und danach nicht mehr angefasst wurde. PHP2Shell macht sie zur betriebskritischen Konfiguration mit Ablaufdatum – sie gehört in die Inventarliste neben Betriebssystem und Firewall-Firmware.

Zweitens: Der Backport für EOL-Zweige ist eine Ausnahme, keine Zusage. Red Hat hat nur Streams innerhalb des eigenen Lebenszyklus bedient; wer auf php:8.1 unter RHEL 9 steht, ist auf Drittanbieter angewiesen. Das ist keine Basis für den Webauftritt einer Kommune.

Drittens: Die Kompatibilitätsmatrix zeigt, dass der Korridor eng wird. Drupal 12 akzeptiert nur noch PHP 8.5, Joomla 6 nichts unter 8.3. Wer heute auf 8.3 oder 8.4 geht, kauft sich ein bis zwei Jahre Ruhe. Wer bei 8.2 stehen bleibt, steht am 1. Januar 2027 wieder vor derselben Frage.

Unsicher, welche PHP-Version auf Ihren Systemen läuft?

Wir nehmen den Bestand auf, prüfen die Kompatibilität Ihrer CMS-Installationen und legen den Update-Pfad fest – inklusive Nachweis für Ihre Dokumentation.

Kontakt aufnehmen