PHP2Shell: Jetzt patchen, Altsysteme gezielt modernisieren

· elbtech

Stand: 21. Oktober 2026, nach Veröffentlichung der PHP-Sicherheitsupdates. Unter dem Namen PHP2Shell werden zwei kritische Schwachstellen in der PHP-Laufzeitumgebung diskutiert: CVE-2026-109618 und CVE-2026-109619. Sie können Angreifern ermöglichen, ohne vorherige Anmeldung Code auf einem Server auszuführen. Die Sofortmaßnahme ist ein Update, kein Wechsel der Programmiersprache. Eine längerfristige Frage ist, wie sich gewachsene Anwendungen anschließend besser warten und bei Bedarf gezielt erneuern lassen.

Was ist passiert?

Das PHP-Projekt hat am 20. Oktober vor einer außerplanmäßigen Sicherheitsveröffentlichung gewarnt und am 21. Oktober die Korrekturen veröffentlicht. Die offiziellen Advisories bewerten beide Schwachstellen mit CVSS 4.0: 9,2. Es geht um Fehler im internen Umgang mit Speicher und dem Zustand aufeinanderfolgender Anfragen – nicht um eine einzelne fehlerhafte PHP-Anwendung.

  • CVE-2026-109618: RCE via OOM corruption. Bei Speichermangel kann die Anfrageverarbeitung unterbrochen werden, während interne Daten noch nicht vollständig initialisiert sind. Die anschließende Bereinigung kann diesen ungültigen Zustand weiterverarbeiten.
  • CVE-2026-109619: RCE via stale global state. Ein Worker kann nach dem Freigeben von Anfrage-Speicher noch Verweise darauf behalten. Eine spätere Anfrage kann diesen veralteten Zustand verwenden.

Welche Systeme müssen geprüft werden?

Laut PHP-Sicherheitsteam sind PHP-Installationen, die Webanfragen verarbeiten, als gefährdet zu behandeln. Dazu gehören PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Die konkreten Angriffsmöglichkeiten hängen unter anderem von Version, Betriebsart, Erweiterungen und Anwendung ab. Für mod_php beschreibt das Team einen bestätigten Angriff vor der Ausführung des Anwendungscodes. Eine gute Anmeldung oder Berechtigungsprüfung in der Anwendung ersetzt das Runtime-Update deshalb nicht. Eine anfällige Installation ist allerdings nicht automatisch der Nachweis eines bereits erfolgten Einbruchs.

Welche Updates stehen bereit?

Beide Lücken sind mit den am 21. Oktober 2026 veröffentlichten Versionen PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 behoben. Installiert für euren PHP-Zweig mindestens diesen Stand oder eine neuere Sicherheitsversion.

Distributions- und LTS-Anbieter können Korrekturen in ihre Pakete zurückportieren. Dann ist die Sicherheitsmeldung des Anbieters maßgeblich, nicht allein die angezeigte Upstream-Versionsnummer. PHP 8.1 und ältere Zweige erhalten keinen regulären Sicherheitssupport mehr vom PHP-Projekt. Für diesen Vorfall hat das Team ausnahmsweise minimale Quellcode-Backports für PHP 7.4, 8.0 und 8.1 bereitgestellt. Das stellt keinen allgemeinen Support dieser Versionen wieder her. Prüft verfügbare Herstellerkorrekturen und plant den Wechsel auf einen unterstützten Stand.

Was Betreiber jetzt tun sollten

  • Betroffene Dienste erfassen: nicht nur öffentlich sichtbare Webseiten, sondern auch Fachanwendungen, eingebettete PHP-Dienste, Container und getrennte Worker-Pools. Zuständigkeit mit Hosting- und Softwareanbietern klären.
  • Die passenden Sicherheitsupdates nach Herstelleranweisung einspielen. Alle betroffenen Worker neu starten beziehungsweise aktualisierte Container-Images tatsächlich ausrollen. Danach den Stand der laufenden Webprozesse überprüfen; eine aktualisierte CLI-Version allein reicht als Nachweis nicht aus.
  • Wenn ein sofortiges Update nicht möglich ist, die öffentliche Erreichbarkeit betroffener Dienste bis zur geprüften Korrektur einschränken oder aussetzen. CERT-EU empfiehlt, diese Isolation zu erwägen. Die PHP-Advisories beschreiben nur unvollständige Konfigurationsmaßnahmen; ein WAF oder ein einzelner Schalter ersetzt den Patch nicht.
  • Bei Verdacht auf einen Einbruch das Incident-Response-Verfahren einschalten und relevante Protokolle und andere Spuren sichern. Ein Update entfernt keine bereits eingeschleuste Hintertür und beweist nicht, dass zuvor kein Zugriff stattgefunden hat.

Erst den Betrieb absichern, dann die Anwendung bewerten

Ein Sicherheitsvorfall ist kein guter Zeitpunkt für eine ungeplante Komplettmigration. Zuerst muss die aktuelle Gefährdung behandelt werden. Danach lohnt ein Blick auf die Voraussetzungen: Ist bekannt, welche Versionen wo laufen? Lassen sich Updates testen und zeitnah ausrollen? Gibt es Verantwortliche, funktionierende Protokolle und einen Rückfallplan? Wenn schon eine Sicherheitsaktualisierung kaum möglich ist, besteht ein Modernisierungsproblem. Dessen Lösung kann ein unterstützter PHP-Stand, ein kleineres Refactoring oder ein gezieltes Reengineering sein – nicht automatisch ein vollständiger Neubau.

Was eine Migration von PHP nach Rust leisten kann

Rust kann eine sinnvolle Zieltechnologie für ausgewählte Dienste oder eine erneuerte Anwendung sein. Sein Ownership-Modell ermöglicht Speichersicherheitsgarantien in sicherem Rust-Code. Die aktuellen PHP-Lücken liegen dagegen in der Laufzeitumgebung; sie lassen sich nicht auf einen Fehler im PHP-Geschäftscode reduzieren. Eine Migration entfernt die Abhängigkeit von dieser Laufzeit nur dort, wo PHP tatsächlich ersetzt wird. Verbleibende PHP-Dienste müssen weiterhin gepatcht werden.

Rust ist keine allgemeine Sicherheitsgarantie. Fehler bei Authentifizierung, Autorisierung, Geschäftsregeln oder Konfiguration bleiben auch dort möglich. Unsafe-Code, native Bibliotheken und Abhängigkeiten brauchen eigene Prüfungen. Ob Rust passt, hängt außerdem vom Team, den benötigten Bibliotheken, den Schnittstellen und dem späteren Betrieb ab. Ein gut gewartetes PHP-System kann die bessere Entscheidung sein als eine überhastete Neuentwicklung.

Reengineering heißt: die Geschäftslogik verstehen

In gewachsener Businesssoftware steckt Wissen, das selten vollständig dokumentiert ist: Berechnungen, Ausnahmen, Freigaben, Datenformate und Verbindungen zu anderen Systemen. Vor einer Ablösung muss klar werden, welches Verhalten erhalten bleiben soll und welches bewusst korrigiert wird. Den alten Code lediglich in einer anderen Sprache nachzubauen, kann auch seine fachlichen Fehler übertragen.

  • Datenflüsse, Schnittstellen und Geschäftsregeln gemeinsam mit den Fachleuten erfassen.
  • Bestehendes Verhalten mit Charakterisierungstests sichtbar machen und Sollverhalten unabhängig davon festlegen. Ein Test gegen das Altsystem ist kein Beweis fachlicher Richtigkeit.
  • Einen abgrenzbaren Teil migrieren und Ergebnisse, Berechtigungen und Fehlerfälle prüfen, bevor weitere Teile folgen.
  • Datenübergang, Rückfallmöglichkeiten und Betriebsüberwachung planen. Parallelbetrieb darf keine unkontrollierten doppelten Buchungen oder anderen Seiteneffekte auslösen.

Wo KI den Aufwand reduzieren kann

KI kann beim Sichten großer Codebestände, beim Auffinden von Abhängigkeiten, beim Vorbereiten von Tests und bei der Umsetzung neuer Komponenten unterstützen. Ihre Beschreibungen und Übersetzungsvorschläge bleiben überprüfbare Annahmen. Entwickler und Fachverantwortliche müssen entscheiden, was die Anwendung tatsächlich leisten soll. Für Quellcode und Projektdaten gelten auch bei dieser Analyse vereinbarte Zugriffs- und Datenschutzgrenzen. Unser Ansatz ist, Effizienzgewinne an Kunden weiterzugeben – nicht eine ungeprüfte automatische Konvertierung oder eine pauschale Halbierung der Projektkosten zu versprechen.

Eine bestehende PHP-Anwendung erneuern

Wir unterstützen KI-gestütztes Reengineering und die Migration gewachsener Businesssoftware, unter anderem mit Rust als Zieltechnologie. Ausgangspunkt sind der Bestand, die benötigten Geschäftsregeln und ein begrenzter erster Umsetzungsschritt. Wenn ihr ein solches Vorhaben plant, könnt ihr mit uns euer PHP-/Rust-Migrationsprojekt besprechen. Akut betroffene Systeme brauchen unabhängig davon die verfügbaren Sicherheitsupdates. Zum Umgang mit KI-generiertem Code findet ihr mehr in unserem Beitrag über sichere Softwareentwicklung mit KI.

Quellen und Aktualität

Die technischen Angaben beruhen auf den folgenden Primärquellen, abgerufen am 21. Oktober 2026. Vor Maßnahmen oder einer späteren Wiederveröffentlichung sind deren aktuelle Fassungen zu prüfen. Wir haben die Exploits nicht selbst ausgeführt und behaupten keine eigenen Kundenbefunde zu PHP2Shell.