Zum Inhalt springen

PHP2Shell: Kritische PHP-Lücken – was TYPO3-Betreiber jetzt prüfen müssen

Am 21. Oktober 2026 hat das PHP-Projekt Advisories zu zwei kritischen Schwachstellen in PHP veröffentlicht. Die Sicherheitsupdates 8.5.12 und 8.4.27 sind seit dem 22. Oktober verfügbar. Die Lücken liegen nicht in TYPO3, ein TYPO3-Update behebt sie deshalb nicht.

Was passiert ist

Das BSI hat unter dem Titel „PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit“ eine Cybersicherheitswarnung veröffentlicht (Version 1.2 vom 22. Oktober 2026). Es geht um zwei Schwachstellen, die in Berichten „PHP2Shell“ heißen:

  • CVE-2026-109618: „RCE via OOM corruption“. PHP bricht bei Speichermangel mit longjmp() die Anfrage ab. Ist der Anfragespeicher zu diesem Zeitpunkt noch nicht vollständig initialisiert, wird er beim Beenden der Anfrage in ungültigem Zustand verarbeitet. Auslösen lässt sich das laut Advisory unter anderem über multipart-Anfragen, also etwa Formular-Uploads.
  • CVE-2026-109619: „RCE via stale global state“. In einem persistenten Worker bleibt Zustand erhalten, der auf Speicher einer bereits beendeten Anfrage zeigt. Ein Angreifer braucht dafür zwei Anfragen, die derselbe Worker bearbeitet.

Beide Lücken erreichen einen CVSS-4.0-Wert von 9,2. Nach Angaben des BSI braucht ein Angreifer weder Anmeldung noch Nutzerinteraktion; er könnte Schadcode auf dem Webserver ausführen. Bestätigt sind Exploits gegen mod_php. Für PHP-FPM ist beim ersten Advisory kein vollständiger Exploit nachgewiesen, beim zweiten ein Pfad über den Session-Upload-Fortschritt gegen mod_php und FPM bestätigt. „Wir nutzen FPM“ ist deshalb keine Entwarnung.

Wer muss was tun

Gepatcht sind die Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Betroffen sind laut Advisory alle Versionen davor. Das Kanadische Zentrum für Cybersicherheit weist zudem darauf hin, dass PHP 8.1 und älter vom PHP-Projekt keine Updates mehr erhalten; manche Distributionen und LTS-Anbieter liefern Backports.

PHP-Zweig auf Ihrem ServerWas zu tun ist
8.5, 8.4, 8.3, 8.2Auf 8.5.12, 8.4.27, 8.3.36 bzw. 8.2.35 oder neuer aktualisieren
8.1 und älterKein offizielles Update des PHP-Projekts. Beim Hoster oder Distributor nachfragen, ob ein Backport mit diesen CVEs vorliegt, oder auf einen unterstützten Zweig wechseln
Gepatchte PHP-Versionen laut Advisories (Stand 23. Oktober 2026)

Praktisch heißt das für Sie als Betreiber:

  1. Klären Sie, welche PHP-Version produktiv läuft und wer sie pflegt. Bei Managed Hosting ist das der Hoster, bei eigenen Servern Ihr Dienstleister. Fragen Sie schriftlich nach dem Stand und dem Termin.
  2. Prüfen Sie nach dem Update die tatsächlich laufende Version, nicht nur die installierte. Worker und Webserver müssen neu gestartet sein; die Advisories nennen den Neustart ausdrücklich für die Workarounds.
  3. Denken Sie an alles, was PHP mitbringt: Staging- und Testsysteme, Container-Images, Nebeninstallationen anderer Anwendungen auf demselben Server. Das BSI weist darauf hin, dass auch Netzwerkkomponenten PHP enthalten können und Hersteller eigene Advisories veröffentlichen.
  4. Planen Sie nach dem Update einen kurzen Check von Login, Formularen und Uploads ein.

Übergangsmaßnahmen, wenn das Update nicht sofort geht

Die PHP-Advisories sagen klar: Das Update ist die „einzige vollständige“ Gegenmaßnahme. Als Überbrückung nennen sie:

  • session.upload_progress.enabled=0 setzen und alle Worker neu starten. Das schließt den Session-Upload-Pfad des zweiten Advisories, aber nicht andere Pfade. Die Autoren empfehlen, die Funktion auch nach dem Patch abzuschalten, wenn Sie sie nicht brauchen.
  • Bei PHP 8.5: fatal_error_backtraces=0 setzen und Worker neu starten.
  • Anfragegrößen begrenzen (unter anderem post_max_size, multipart-Teile, Uploads) und multipart-Anfragen am Frontend blockieren, sofern Ihre Website keine braucht. Bei TYPO3 mit Formularen oder Uploads dürfte das in der Regel nicht möglich sein (unsere Einschätzung).
  • RLIMIT_AS und RLIMIT_DATA vermeiden, weil sie den verwundbaren Pfad auslösen können.

Diese Einstellungen gehören in die Hände Ihres Dienstleisters. Sie sind ein Notbehelf, kein Ersatz.

Lage und offene Punkte

Nach dem BSI sind bislang keine bestätigten Ausnutzungen bekannt, es gibt aber unbestätigte Berichte über existierende Exploits; eine erfolgreiche Ausnutzung in der Breite ist dem BSI nicht bekannt. Das Kanadische Zentrum verweist auf Berichte, wonach ein Proof of Concept existiert, hat bislang keine aktive Ausnutzung festgestellt und schreibt, die Lage könne sich schnell ändern. Medienberichte nennen Behörden und Einrichtungen, die vorsorglich Server vom Netz genommen haben.

Außerdem meldet das Kanadische Zentrum eine dritte, separate Lücke, CVE-2026-115560, die am 23. Oktober veröffentlicht wurde und von den Updates zu den ersten beiden Lücken nicht behoben wird. Sie erfordert nach dortiger Darstellung eine ungewöhnliche Kombination aus PHP-Konfiguration und Anwendungsverhalten; empfohlen wird bis zu einem Fix session.upload_progress.enabled=0. Diese Angabe haben wir nur aus dieser einen Quelle, ein PHP-Advisory dazu haben wir nicht geprüft. Beobachten Sie die Seite des PHP-Projekts auf ein Folgerelease.

Quellen

TYPO3
Zurück