Wer eine Website, einen Onlineshop oder eine Webanwendung auf PHP betreibt, sollte heute nichts anderes tun als aktualisieren. Seit Mittwoch, 21. Oktober, 16 Uhr deutscher Zeit, stehen Updates für zwei kritische Schwachstellen in der Programmiersprache selbst bereit: CVE-2026-109618 und CVE-2026-109619, in Sicherheitskreisen „PHP2Shell“ genannt. Beide erhalten nach CVSS 4.0 den Wert 9,2 von 10. Ein Angreifer braucht weder Zugangsdaten noch die Mithilfe eines Nutzers, um im schlimmsten Fall eigenen Code auf dem Server auszuführen.
Geschlossen sind die Lücken ab PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 (Details in der Tabelle unten). Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat die Lage mit der Kritikalität „3 / Orange“ eingestuft – Maßnahmen müssen demnach „unverzüglich“ ergriffen werden.
Was steckt hinter PHP2Shell?
Beide Fehler sitzen in der PHP-Laufzeitumgebung, nicht in einer bestimmten Anwendung. Das PHP-Projekt beschreibt sie in seinem Advisory so:
- CVE-2026-109618 betrifft die Behandlung von Speichermangel. Erreicht PHP sein Speicherlimit, kann die Verarbeitung an einer Stelle abbrechen, an der interne Anfragedaten erst halb eingerichtet sind. Beim Aufräumen werden diese unvollständigen Daten später als gültig behandelt.
- CVE-2026-109619 betrifft internen Zustand, der eigentlich nur zu einer Anfrage gehört. Er kann weiterbestehen, obwohl der zugehörige Speicher schon freigegeben ist – und eine folgende Anfrage im selben Worker-Prozess greift dann darauf zu.
Gefährdet ist laut PHP jede Installation, die Webanfragen verarbeitet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Nach Angaben von heise sind die Lücken bis mindestens PHP 5 zurück vorhanden, auch Windows-Server sind betroffen. Weitere technische Details zur Ausnutzung lassen wir bewusst weg.
Warum betrifft das so viele Websites?
PHP ist das Fundament eines großen Teils des Webs. Das BSI nennt ausdrücklich WordPress, Drupal, TYPO3, Joomla, Magento und Nextcloud, dazu Firewall-Systeme wie pfSense und OPNsense. Hinzu kommen unzählige Eigenentwicklungen, Intranets und Verwaltungsportale. Entscheidend: Auch eine perfekt gepflegte WordPress-Installation mit aktuellen Plugins ist angreifbar, solange darunter ein altes PHP läuft. Ein Update des CMS hilft hier nicht.
Laut heise steckt PHP außerdem in den Verwaltungsoberflächen vieler Geräte, etwa von NAS-Systemen, Routern und Security-Appliances. Ob ein bestimmtes Gerät betroffen ist, müssen die Hersteller klären. Das BSI verweist auf eine Liste betroffener Produkte, die das niederländische NCSC auf GitHub sammelt und laufend erweitert.
Welche Version ist sicher?
| PHP-Zweig | Status | Sicher ab |
|---|---|---|
| 8.5 | unterstützt | 8.5.12 |
| 8.4 | unterstützt | 8.4.27 |
| 8.3 | nur noch Sicherheitsupdates | 8.3.36 |
| 8.2 | Sicherheitsupdates bis Jahresende | 8.2.35 |
| 8.1, 8.0, 7.4 | End of Life | kein Release, nur Quellcode-Backport |
| 7.3 und älter | End of Life | keine Korrektur vom PHP-Projekt |
Für 7.4, 8.0 und 8.1 hat das PHP-Sicherheitsteam minimale Backport-Patches als Quellcode bereitgestellt. Das hilft vor allem Admins, die PHP selbst kompilieren. Wer eine Linux-Distribution nutzt, bekommt die Korrektur meist als zurückportiertes Paket von Debian, Ubuntu oder Red Hat – die Versionsnummer allein sagt dann wenig, maßgeblich sind die Sicherheitshinweise der Distribution. Docker-Images müssen neu gebaut werden.
Wird die Lücke schon ausgenutzt?
Bestätigt ist das bislang nicht. Die US-Behörde CISA hatte zum Zeitpunkt ihrer Warnung keine Angriffe beobachtet, das BSI ebenfalls nicht. In sozialen Medien kursieren laut BSI zwar Berichte über erste Angriffsversuche, diese ließen sich aber nicht verifizieren. Ein Proof of Concept ist öffentlich.
Entwarnung ist das nicht. Das BSI hält eine breite Ausnutzung innerhalb weniger Stunden nach Erscheinen der Patches für wahrscheinlich, weil Angreifer Patches mit KI-Werkzeugen heute schnell analysieren. Zudem waren die Details früher öffentlich geworden als geplant. Wie schnell so etwas geht, zeigten zuletzt die WordPress-Lücke CVE-2026-87902 und die Roundcube-Lücke, die kurz nach den Updates angegriffen wurden.
Was Betreiber jetzt tun sollten
- Inventur: Alle Systeme mit PHP erfassen – auch vergessene Testserver, Container und Geräte mit Weboberfläche. Mit
php -vlässt sich die Version prüfen; bei Webservern zählt die Version, die PHP-FPM oder Apache tatsächlich nutzt. - Sofort patchen: Auf die Versionen aus der Tabelle oder die Pakete der Distribution aktualisieren, danach PHP-FPM bzw. Apache neu starten. Öffentlich erreichbare Server zuerst.
- Hosting-Kunden: Beim Provider nachfragen, ob das Update eingespielt ist und ob der eigene Tarif noch auf PHP 8.2 oder neuer läuft.
- Wenn das Update warten muss: BSI und CISA raten, betroffene Systeme vorübergehend vom Internet zu trennen. Eine Web Application Firewall kann bekannte Angriffswege blockieren; Anbieter wie Cloudflare haben laut BSI entsprechende Regeln veröffentlicht.
- Übergangslösungen nur als Krücke: Das PHP-Projekt nennt Konfigurationsänderungen, die die Angriffsfläche verkleinern. Es betont aber, dass es keine vollständige Absicherung gibt – „updating is the only safe choice“. heise hält die oft genannte Einstellung
session.upload_progress.enabled = 0allein für unzureichend. - Auffälligkeiten beobachten: CISA empfiehlt, auf ungewöhnliche Prozesse zu achten, etwa PHP-Worker, die eine Shell starten.
Für Unternehmen gilt zusätzlich: Gelangen Angreifer über eine Lücke an personenbezogene Daten, kann eine Meldepflicht nach DSGVO greifen – in der Regel binnen 72 Stunden bei der zuständigen Datenschutzaufsicht.
Wie ernst ist die Lage im Vergleich?
Das BSI zieht selbst den Vergleich zu Log4Shell, der Java-Lücke von Ende 2021, die über Monate ausgenutzt wurde. Der Spitzname PHP2Shell ist bewusst daran angelehnt. Der Unterschied: Bei PHP ist nicht eine Bibliothek, sondern die Laufzeitumgebung selbst betroffen – und damit praktisch jede PHP-Anwendung, die Anfragen aus dem Netz annimmt. Hinzu kommt der große Bestand an veralteten Versionen: Alles vor 8.2 hat das End of Life bereits erreicht, auch 8.2 erhält nur noch bis Jahresende Sicherheitsupdates. Das BSI rät deshalb, grundsätzlich auf eine unterstützte Version zu migrieren.
Häufige Fragen
Bin ich als Besucher einer Website betroffen?
Nein, direkt nicht. Handeln müssen Betreiber, Hoster und Admins. Wird ein Server allerdings übernommen, können dort gespeicherte Kundendaten in falsche Hände geraten.
Reicht ein WordPress- oder Shop-Update?
Nein. Die Lücke steckt in PHP auf dem Server. Nur eine korrigierte PHP-Version oder ein Paket-Update der Distribution schließt sie.
Mein Server läuft noch mit PHP 7.4 oder 8.1 – was tun?
Ein offizielles Release gibt es dafür nicht. Möglich sind die Quellcode-Backports des PHP-Teams oder Patches der Distribution bzw. eines LTS-Anbieters. Langfristig führt kein Weg an PHP 8.2 oder neuer vorbei.
Warum sind einige Websites gerade offline?
Mehrere Betreiber haben ihre Server vorsorglich vom Netz genommen, bis die Updates eingespielt sind. Das BSI berichtet deshalb von eingeschränkter Erreichbarkeit einzelner Websites in Deutschland.
