Ende Oktober 2026 lag in vielen IT-Abteilungen dieselbe Meldung auf dem Tisch: zwei kritische Sicherheitslücken in PHP, über die Angreifer im schlimmsten Fall eigenen Code auf dem Server ausführen können. In der Sicherheitsszene bekamen sie schnell einen griffigen Namen, „PHP2Shell“. Betroffen ist nicht eine bestimmte Anwendung, sondern der PHP-Interpreter selbst, also das Programm, das jede PHP-Anwendung ausführt. Damit stehen der Firmenauftritt auf WordPress, der Onlineshop mit Shopware und die über Jahre gewachsene Eigenentwicklung gleichermaßen auf der Liste.

Fast zeitgleich veröffentlichte AWS eine Anleitung, wie sich PHP-Anwendungen mit KI-Unterstützung nach Java übertragen lassen. Und am 31. Dezember 2026 endet der Sicherheitssupport für PHP 8.2. Wer diese drei Nachrichten nebeneinanderlegt, könnte schließen, PHP sei ein Auslaufmodell. Das wäre ein Fehlschluss. Das Sicherheitsproblem sind veraltete PHP-Versionen, nicht die Sprache. Welche Konsequenzen sich daraus ergeben, hängt von Ihrer Ausgangslage ab.

Was über PHP2Shell bekannt ist

Am 21. Oktober 2026 veröffentlichte das PHP-Projekt die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Sie schließen zwei Lücken, die als kritisch eingestuft sind, beide mit einem CVSS-Wert von 9,2. CVSS ist eine Skala von 0 bis 10, mit der Schwachstellen nach Schwere bewertet werden.

• CVE-2026-109618 betrifft die Behandlung von Speicherengpässen (Out of Memory). Ein Speicherfehler in diesem Pfad lässt sich zur Codeausführung missbrauchen.
• CVE-2026-109619 beruht auf veraltetem globalem Zustand, also auf internen Daten, die nach einer Anfrage nicht sauber zurückgesetzt werden. Auch hier ist Codeausführung möglich.

Alle Versionen vor diesen Fix-Releases gelten als verwundbar. Laut dem Sicherheitsunternehmen watchTowr reicht das zurück bis in die längst nicht mehr gepflegten Zweige von PHP 5. Sicherheitsforscher berichten zudem von Angriffen, die die Lücken bereits ausnutzen, und die US-Behörde CISA führt beide seit dem 26. Oktober 2026 in ihrem Katalog aktiv ausgenutzter Schwachstellen. Das europäische CERT-EU nennt außerdem eine dritte Lücke, CVE-2026-115560, zu der es noch keine Details gibt. Das PHP-Team hat angekündigt, sie mit dem nächsten Release vollständig zu beschreiben.

Was jetzt sofort zu tun ist

Für Systeme mit einer unterstützten PHP-Version ist die Lösung unspektakulär: Patch-Release einspielen. Der Teufel steckt in der Frage, wo überall PHP läuft.

1. Version prüfen, und zwar auf jedem Server, nicht nur auf dem Entwicklungsrechner. php -v zeigt die Kommandozeilenversion. Der Webserver nutzt oft eine eigene Installation, etwa PHP-FPM (der Prozessmanager, der PHP-Anfragen für Nginx oder Apache abarbeitet).
2. Container-Images neu bauen. Ein Docker-Image enthält eine feste PHP-Version. Solange niemand es neu baut und ausrollt, läuft dort der alte Stand weiter, auch wenn der Host längst aktualisiert ist.
3. Distributionspakete aktualisieren. Wer PHP aus den Paketquellen von Debian, Ubuntu oder Red Hat bezieht, bekommt die Korrekturen über die Distribution. Deren Versionsnummern weichen oft von den offiziellen ab, entscheidend ist der Hinweis im Änderungsprotokoll des Pakets.
4. Hoster fragen. Bei Shared Hosting oder Managed Hosting liegt das Update beim Anbieter. Lassen Sie sich bestätigen, dass es eingespielt ist.

Angenommen, ein Mittelständler betreibt seinen Shop auf PHP 8.3. Dann bedeutet PHP2Shell ein Update auf 8.3.36, einen Neustart von PHP-FPM und einen kurzen Funktionstest. Ein Projekt ist das nicht.

Der Support-Kalender: welche PHP-Versionen noch Updates bekommen

Schwierig wird es für alle, deren Version gar keine Korrekturen mehr erhält. Seit 2024 gilt beim PHP-Projekt ein fester Rhythmus: zwei Jahre aktiver Support mit Fehlerbehebungen, danach zwei Jahre reine Sicherheitsupdates. Beide Phasen enden jeweils am 31. Dezember.

PHP 8.6 befindet sich in der Testphase. Für Produktivsysteme spielt es noch keine Rolle.

„End of Life“ heißt praktisch: Das PHP-Projekt veröffentlicht für diese Version keine Releases mehr, auch nicht bei kritischen Lücken. Für PHP 8.1 und ältere Versionen gibt es deshalb kein offizielles Release gegen PHP2Shell. Wegen der Schwere der Lücken hat das PHP-Sicherheitsteam lediglich minimale Korrekturen im Quellcode für PHP 7.4, 8.0 und 8.1 bereitgestellt, gedacht für alle, die PHP selbst kompilieren. Hinzu kommt ein Effekt, der oft unterschätzt wird: Frameworks und Bibliotheken stellen die Unterstützung alter PHP-Versionen ebenfalls ein. Wer auf PHP 7.4 festhängt, bekommt meist auch keine Sicherheitsupdates mehr für Laravel, Symfony oder die eingesetzten Composer-Pakete.

Weg 1: Upgrade auf PHP 8.4 oder 8.5

Für die meisten Anwendungen ist das Versions-Upgrade der naheliegende Weg. Das Ziel sollte eine Version mit möglichst langer Restlaufzeit sein, also 8.4 oder 8.5. Ein Sprung auf 8.3 löst das Problem nur für ein gutes Jahr.

Ein Vorgehen, das sich bewährt

Ein Upgrade ist keine Frage des Mutes, sondern der Vorbereitung. Sinnvoll ist diese Reihenfolge:

1. Bestandsaufnahme: Welche PHP-Version läuft wo, welche Erweiterungen sind installiert, welche Cronjobs und Hintergrundprozesse gibt es?
2. Abhängigkeiten prüfen: composer outdated zeigt veraltete Pakete, composer audit meldet Pakete mit bekannten Sicherheitslücken. Oft blockiert nicht der eigene Code das Upgrade, sondern eine Bibliothek, die seit Jahren keine neue Version bekommen hat.
3. Statische Analyse: Werkzeuge wie PHPStan oder Psalm lesen den Code, ohne ihn auszuführen, und finden Typfehler und Aufrufe entfernter Funktionen. PHPCompatibility, eine Regelsammlung für PHP_CodeSniffer, prüft gezielt, welche Stellen mit einer Zielversion kollidieren.
4. Automatisierte Umbauten: Rector schreibt Code nach festen Regeln um, etwa veraltete Syntax in die aktuelle Form. Das spart viel Handarbeit und ist wiederholbar.
5. Tests: Ohne automatisierte Tests bleibt jedes Upgrade ein Blindflug. Wo keine existieren, helfen zunächst einige Ende-zu-Ende-Tests für die wichtigsten Abläufe, etwa Anmeldung, Bestellung und Rechnungsversand.
6. Schrittweise vorgehen: Bei großen Sprüngen lohnt es sich, Zwischenversionen anzusteuern und jede Stufe einzeln zu testen. So bleibt nachvollziehbar, welche Änderung welchen Fehler verursacht.

Eine Rector-Konfiguration für das Ziel PHP 8.4 kann so aussehen:

<?php
// rector.php – Regeln für das Upgrade auf PHP 8.4
use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([
        __DIR__ . '/src',
        __DIR__ . '/tests',
    ])
    // alle Umbauregeln bis einschließlich PHP 8.4
    ->withPhpSets(php84: true)
    // zusätzlich toten Code entfernen und Typangaben ergänzen
    ->withPreparedSets(deadCode: true, typeDeclarations: true);

Mit vendor/bin/rector process --dry-run sehen Sie zunächst nur die vorgeschlagenen Änderungen, ohne dass Dateien angefasst werden. Ebenso wichtig ist die Angabe der Zielplattform in der composer.json. Sie sorgt dafür, dass Composer nur Paketversionen installiert, die zur Produktionsumgebung passen, auch wenn auf dem Entwicklungsrechner eine andere PHP-Version läuft:

{
  "require": {
    "php": "^8.4"
  },
  "config": {
    "platform": {
      "php": "8.4.27"
    }
  }
}

Typische Stolpersteine beim Sprung von 7.4 auf 8.x

Wer von PHP 7.4 kommt, trifft auf einige Änderungen, die alten Code brechen. Mit PHP 8 wurde die Typprüfung strenger: Viele eingebaute Funktionen werfen bei falschen Argumenten einen Fehler, wo sie früher nur eine Warnung ausgaben und weiterliefen. Vergleiche zwischen Zahlen und Zeichenketten verhalten sich anders als zuvor. Etliche Funktionen, die schon länger als veraltet (deprecated) markiert waren, sind entfernt.

Ab PHP 8.2 sind zudem dynamische Properties veraltet. Gemeint sind Eigenschaften, die ein Objekt zur Laufzeit erhält, ohne dass die Klasse sie deklariert. Älterer Code nutzt das häufig, etwa um Datenbankzeilen in beliebige Objekte zu schreiben. PHP gibt dafür vorerst nur Hinweise aus, aber die sollten Sie als Arbeitsliste lesen. Das Attribut #[\AllowDynamicProperties] kann solche Klassen übergangsweise kennzeichnen. Die saubere Lösung bleibt, die Eigenschaften zu deklarieren.

Für Anwendungen auf Laravel oder Symfony kommt das Framework-Upgrade hinzu, denn neuere Framework-Versionen setzen neuere PHP-Versionen voraus und umgekehrt. Bei der Planung hilft der Blick auf die jeweiligen Upgrade-Leitfäden. Für Teams, die diesen Weg zum ersten Mal gehen, bieten wir Beratung und Seminare rund um Laravel an.

Weg 2: Zeit kaufen mit Backports und Extended Support

Nicht jede Anwendung lässt sich bis zum Jahresende umstellen. Dann gibt es zwei Möglichkeiten, Zeit zu gewinnen.

Erstens die Backports der Linux-Distributionen. Debian und andere Distributionen pflegen die PHP-Version, die sie ausgeliefert haben, oft über das offizielle Support-Ende hinaus. Sie übertragen Sicherheitskorrekturen aus neueren Versionen in ihre eigenen Pakete. Für PHP2Shell liefern Distributionen solche gepatchten Pakete auch für Zweige, für die das PHP-Projekt selbst keine Releases mehr veröffentlicht. Voraussetzung ist, dass PHP tatsächlich aus den Paketquellen der Distribution stammt und die Distributionsversion selbst noch gepflegt wird.

Zweitens kommerzieller Extended Support. Verschiedene Anbieter verkaufen Sicherheitsupdates für PHP-Versionen jenseits ihres Lebensendes. Das kann für eine geschäftskritische Anwendung eine vernünftige Brücke sein.

Beide Varianten sind ehrlich betrachtet ein Übergang, kein Ziel. Sie halten den Interpreter sicher, aber nicht das, was darauf läuft. Framework und Bibliotheken veralten trotzdem weiter, neue Paketversionen setzen neuere PHP-Versionen voraus, und mit jedem Monat wird der spätere Sprung größer. Wer diesen Weg wählt, sollte gleichzeitig einen Termin für das Upgrade festlegen.

Weg 3: Sprachwechsel – was der AWS-Ansatz zeigt

Am 29. Oktober 2026 beschrieb AWS in seinem Machine-Learning-Blog, wie sich eine „wiederholbare Migrationsmaschine“ von PHP nach Java bauen lässt. Der Ansatz ist durchdacht und verdient einen genauen Blick.

Der bestehende PHP-Code gilt dabei als Spezifikation, also als verbindliche Beschreibung dessen, was die neue Anwendung tun muss. Ein sogenanntes Parity-Harness, eine Testumgebung für den Verhaltensvergleich, prüft, ob PHP- und Java-Version auf dieselben Eingaben dieselben Ergebnisse liefern. Die Migration läuft laut AWS in acht Phasen, nummeriert von 0 bis 8: Bestandsaufnahme per Scanner, Aufbau des Parity-Harness, ein Regelwerk (RULEBOOK.md) und eine Liste offener Lücken (GAP_INVENTORY.md), ein Härtetest dieses Regelwerks, danach Gerüst, Datenmodell, Ein- und Ausgabe, Geschäftslogik und schließlich Nachweis und Umstellung. Die Arbeit übernimmt Kiro, die KI-Entwicklungsumgebung von AWS, wobei Menschen jede Phase freigeben. Für ganze Anwendungsportfolios verweist AWS alternativ auf seinen Dienst AWS Transform. Laut AWS erkennt der Ansatz Laravel, Symfony, CodeIgniter und reines PHP.

Bemerkenswert ist, welche Gründe AWS für den Wechsel nennt: Typsicherheit, die Auswahl an Bibliotheken und planbare Skalierung. Sicherheit gehört nicht dazu. Ebenso aufschlussreich ist das Beispiel: Von 37 Modellen einer Laravel-Beispielanwendung wurden 4 nach Spring Boot 3.4 auf Java 21 übertragen. Die Autoren nennen selbst als größte Lücke, dass für diesen Ausschnitt kein Parity-Harness existiert. Das ist ein ehrlicher Werkstattbericht, aber kein Beleg, dass sich eine komplette Anwendung auf Knopfdruck übersetzen lässt.

Wann ein Sprachwechsel trotzdem sinnvoll ist

Gegen PHP2Shell hilft ein Sprachwechsel nicht. Bis die neue Anwendung produktiv läuft, muss die alte ohnehin gepatcht werden. Und auch Java-Anwendungen brauchen laufend Updates für Laufzeitumgebung, Frameworks und Bibliotheken, wie unser Beitrag zu sicherem Programmieren in Java zeigt.

Es gibt aber gute Gründe aus anderer Richtung:

• Teamkompetenz: Das Unternehmen hat ein starkes Java- oder .NET-Team, aber kaum noch PHP-Kenntnisse im Haus.
• Plattformstrategie: Die übrigen Systeme laufen auf einer gemeinsamen Plattform, und die PHP-Anwendung ist ein Fremdkörper im Betrieb.
• Architekturumbau: Die Anwendung muss ohnehin grundlegend neu geschnitten werden, etwa weil ein Monolith in Dienste zerlegt oder die Datenhaltung umgestellt wird.

Der Preis ist hoch. Ein Sprachwechsel bindet das Team über lange Zeit, Fachlogik kann unterwegs verloren gehen, und während der Migration müssen zwei Systeme gepflegt werden. Wer diesen Weg prüft, findet in unserer Beratung zur Migration von Legacy-Software Unterstützung bei Bestandsaufnahme und Planung.

Was sich vom AWS-Ansatz übertragen lässt, auch ohne Sprachwechsel

Interessanter als die Zielsprache sind die Methoden, die AWS beschreibt. Sie funktionieren ebenso bei einem großen Versions-Upgrade innerhalb von PHP.

• Verhalten vergleichen statt hoffen: Lassen Sie alte und neue Version mit denselben Eingaben laufen und vergleichen Sie die Ausgaben. Angenommen, ein Webshop wird von PHP 7.4 auf 8.4 gehoben: Dann können aufgezeichnete Anfragen gegen beide Stände geschickt und die Antworten automatisch abgeglichen werden. Abweichungen bei Preisberechnung oder Rundung fallen so auf, bevor Kunden sie bemerken.
• Regelwerk statt Handkorrekturen: Der AWS-Grundsatz „fix the loop, not the code“ heißt: Wenn ein automatischer Umbau falsch ist, korrigieren Sie die Regel und lassen neu generieren, statt das Ergebnis von Hand nachzubessern. Mit Rector lässt sich das genauso umsetzen. Der Vorteil: Die Korrektur gilt für alle Stellen und bei jedem weiteren Durchlauf.
• KI-Agenten für wiederholbare Umbauten: Sprachmodelle eignen sich gut für gleichförmige Änderungen über viele Dateien. Sinnvoll eingesetzt werden sie in klar abgegrenzten Phasen, mit einer Freigabe durch einen Menschen nach jeder Phase und mit Tests als Schiedsrichter.

Welcher Weg zu welcher Ausgangslage passt

Die Entscheidung lässt sich auf wenige Fragen zurückführen: Welche Version läuft heute, wie gut ist der Code getestet, und gibt es Gründe für einen Umbau, die mit Sicherheit nichts zu tun haben?

Für die verbleibenden Wochen bis Jahresende ergibt sich daraus eine kurze Liste: alle PHP-Installationen inventarisieren, einschließlich Container und Hosting; die Patch-Releases einspielen; für jede Anwendung auf PHP 8.2 oder älter einen Upgrade-Termin festlegen; und mit composer audit prüfen, welche Abhängigkeiten zusätzlich Lücken mitbringen.

Was das für Ihr Unternehmen bedeutet

PHP2Shell ist ernst, aber kein Grund für Panik und schon gar kein Argument gegen PHP. Unternehmen mit gepflegten Versionen haben die Lücken mit einem Routine-Update erledigt. Unter Druck geraten diejenigen, die Updates jahrelang aufgeschoben haben, und für sie ist die eigentliche Lehre organisatorisch: Regelmäßige kleine Upgrades sind überschaubar, ein Sprung über mehrere Versionen auf einmal ist ein Projekt.

Unsere Einschätzung: Für die große Mehrheit der PHP-Anwendungen ist das Upgrade auf 8.4 oder 8.5 der richtige Weg. Backports und Extended Support sind legitime Brücken, solange am anderen Ende ein Termin steht. Ein Sprachwechsel kann sinnvoll sein, muss sich aber mit Teamstruktur, Plattform oder Architektur begründen lassen. Wer ihn mit Sicherheitslücken begründet, tauscht ein Update-Problem gegen ein anderes.

Wie sich die Sprache selbst entwickelt hat und warum sie trotz aller Unkenrufe weiter einen großen Teil des Webs trägt, beschreibt unser Überblick PHP heute.

Häufige Fragen zu PHP2Shell und PHP-Upgrades

Reicht es, nur den Webserver neu zu starten?

Nein. Erst muss die gepatchte PHP-Version installiert sein, danach sind PHP-FPM und gegebenenfalls Worker-Prozesse neu zu starten. Bei Containern gehört das Neubauen und Ausrollen der Images dazu.

Ist eine WordPress-Seite betroffen, wenn alle Plugins aktuell sind?

Ja, sofern die PHP-Version darunter nicht gepatcht ist. Die Lücken liegen im Interpreter, nicht in WordPress oder seinen Erweiterungen. Aktuelle Plugins schützen davor nicht.

Lässt sich direkt von PHP 7.4 auf 8.5 springen?

Technisch ja, praktisch ist es meist einfacher, in Etappen vorzugehen und jede Stufe zu testen. Entscheidend ist weniger die Zahl der Schritte als die Frage, ob alle Composer-Abhängigkeiten in Versionen verfügbar sind, die die Zielversion unterstützen.

Ist Java sicherer als PHP?

Diese Frage lässt sich nicht pauschal beantworten. Auch Java-Laufzeitumgebungen und -Frameworks haben regelmäßig kritische Lücken. Sicher ist eine Anwendung in beiden Sprachen dann, wenn Laufzeit, Frameworks und Bibliotheken gepflegt werden.