PHP2Shell: die kurze Antwort

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen, bekannt als PHP2Shell (CVE-2026-109618 und CVE-2026-109619). Über sie können Angreifer ohne Anmeldung Code auf einem Server ausführen. Reguläre Updates des PHP-Projekts gibt es nur für die unterstützten Zweige 8.2 bis 8.5; für ältere Versionen gibt es höchstens Quellcode-Korrekturen oder Pakete einzelner Anbieter. Nach einer Auswertung des Scan-Anbieters Modat liefen am Tag vor dem Patch rund 79 Prozent der PHP-Dienste, deren Version sich auslesen ließ, auf Zweigen, die das PHP-Projekt nicht mehr pflegt.

Für eine unterstützte PHP-Version ist das Update die einfachste Lösung. Prüfe danach, ob die korrigierte Version tatsächlich läuft und ob es Hinweise auf einen Einbruch gibt. Wenn dein System kein Update mehr bekommen kann, stehen Aktualisierung, Überbrückung oder Ablösung an.

In diesem Artikel findest du, was belegt ist und was nicht, was Behörden raten, was du sofort tun solltest und welche Wege es für ältere PHP-Systeme gibt.

Was am 21. Oktober passiert ist

PHP ist die Programmiersprache hinter einem großen Teil des Webs. Laut W3Techs nutzen 69,3 Prozent der Websites, deren serverseitige Sprache bekannt ist, PHP; bei Websites mit der Endung .de sind es unter derselben Voraussetzung 77,7 Prozent (Stand: 22. Oktober 2026). Dazu gehören Content-Management-Systeme, Onlineshops, Kundenportale und viele selbst entwickelte Anwendungen im Mittelstand.

Das PHP-Projekt hat am 21. Oktober die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Sie beheben die beiden Lücken, die Codeausführung ohne Anmeldung ermöglichen können. Beide bewertet das PHP-Projekt in seinen Sicherheitshinweisen (CVE-2026-109618, CVE-2026-109619) mit 9,2 von 10 Punkten nach CVSS 4.0. Technisch geht es um Speicherfehler: Unter bestimmten Bedingungen bleibt Speicher eines Requests in einem ungültigen Zustand zurück und lässt sich für eingeschleusten Code missbrauchen.

Gefährdet sind laut PHP alle Installationen, die Web-Requests verarbeiten, ausdrücklich auch PHP-FPM, php-cgi, FrankenPHP und LiteSpeed. Am höchsten schätzt PHP das Risiko bei Apache mit mod_php ein; dort ist Codeausführung ohne Anmeldung nachgewiesen. Für PHP-FPM ist sie über den Session-Weg ebenfalls bestätigt, abhängig von der Anwendung.

Gefunden wurden die Lücken mit Hilfe von KI. Nach eigener Darstellung meldete das Sicherheitsunternehmen Calif im August 2026 den ersten Fehler an PHP, im Rahmen von OpenAIs Programm „Patch the Planet“. Auch Wiz fand die Lücken nach eigener Angabe im August und meldete sie an PHP. Wiz schreibt, aktuelle KI-Modelle hätten die Hürde für einen funktionierenden Angriff deutlich gesenkt.

Welche Versionen betroffen sind

Hier unterscheiden sich die Quellen, und genau das ist für ältere Systeme wichtig:

  • Das PHP-Projekt nennt korrigierte Releases für die Zweige 8.2 bis 8.5. Das schließt eine Betroffenheit älterer Versionen nicht aus. PHP 8.1 und älter bekommen keine regulären Updates mehr vom PHP-Projekt. Für PHP 7.4, 8.0 und 8.1 hat das Sicherheitsteam minimale Quellcode-Korrekturen bereitgestellt, die Betreiber selbst übersetzen müssen. Reguläre Releases oder fertige Binärpakete sind das nicht.
  • Die Entdecker sehen die Lücken deutlich weiter zurück: Laut Wiz ist jede PHP-Version der letzten zehn Jahre von mindestens einer der beiden Lücken betroffen, Calif nennt PHP 5.4 als früheste betroffene Version.
  • Das BSI schreibt in seiner Cybersicherheitswarnung (Version 1.2 vom 22. Oktober) von einer Verwundbarkeit bis mindestens PHP 5.
  • Linux-Distributionen liefern teils eigene Korrekturen für ältere Versionen nach. Ubuntu führt für beide Lücken PHP 8.1 in Ubuntu 22.04 als regulär korrigiertes Paket. Für ältere PHP-7- und PHP-5-Pakete verweist Ubuntu dagegen auf erweiterten Support. Entscheidend sind Distribution und Paketstand, nicht allein die PHP-Versionsnummer.

Wird die Lücke schon ausgenutzt?

Es gibt Angriffe und Angriffsversuche. Eine belastbare Gesamtzahl tatsächlich kompromittierter Systeme nennen die hier geprüften Quellen nicht.

  • Amazon sah schon am 17. Oktober, also vor der Veröffentlichung, einen Ausnutzungsversuch in seinem Honeypot-Netz. Ob dieser auf echten Systemen erfolgreich gewesen wäre, sei unklar. Für die Zeit nach der Veröffentlichung berichtet Amazon von breiter Ausnutzung, ohne eine Zahl bestätigter Opfer zu nennen.
  • Cloudflare hat ab dem frühen Morgen des 21. Oktober Schutzregeln für seine Web Application Firewall ausgerollt und Angriffsverkehr auf Kunden beobachtet. watchTowr meldet Ausnutzung in seinen Honeypots.
  • Die US-Behörde CISA hatte bei Veröffentlichung ihrer Warnung am 21. Oktober noch keine Ausnutzung beobachtet. Dem BSI lagen laut Update vom 22. Oktober keine bestätigten Meldungen über erfolgreich kompromittierte Systeme aus der regulierten Wirtschaft oder der Bundesverwaltung vor. Diese Aussagen betreffen unterschiedliche Zeitpunkte und Beobachtungsbereiche; sie widerlegen die Angriffsmeldungen nicht.

Spürbar war die Lage trotzdem: Das BSI berichtet von Betreibern, die PHP-Webserver vorsorglich vom Internet trennten. Dadurch waren verschiedene Websites in Deutschland zeitweise eingeschränkt erreichbar. Laut Reuters nahm etwa der IT-Dienstleister des Bundes, ITZBund, mehrere Websites rein vorsorglich vom Netz; Sicherheitsvorfälle waren nicht bekannt. Solche Abschaltungen belegen für sich genommen keinen Einbruch.

Was Behörden raten

  • CISA: Sofort patchen, öffentlich erreichbare Systeme zuerst. Wer nicht sofort aktualisieren kann oder noch PHP 8.1 oder älter einsetzt, solle PHP-Systeme vom Netz nehmen, bis sie gepatcht oder aktualisiert sind. Eine Web Application Firewall könne bis dahin einen gewissen Schutz bieten.
  • BSI: Wenn Patches nicht umgehend installiert werden können, empfiehlt das BSI, eine vorübergehende Trennung vom Internet zu erwägen, weil Workarounds keinen vollständigen Schutz bieten. Auch in Docker-Containern betriebene PHP-Anwendungen müssen aktualisiert oder neu gebaut werden.
  • CERT-EU und eine gemeinsame Erklärung europäischer Stellen unter Beteiligung von ENISA raten, eine Isolierung exponierter Anwendungen vom öffentlichen Netz zu erwägen.

Was du jetzt tun solltest

  1. Finde jede PHP-Installation. Nicht nur die Website, auch Kundenportale, interne Werkzeuge, Container-Images, Software von Drittanbietern und Geräte mit Weboberfläche. Das BSI verweist auf eine Produktübersicht des niederländischen NCSC. Sie enthält auch noch ungeklärte Fälle und ersetzt die Herstellerprüfung nicht. Frag deine Dienstleister und Hoster, welche PHP-Version bei ihnen läuft und ob beide Lücken behoben sind.
  2. Patche, wo es ein Update gibt. Für 8.2 bis 8.5 heißt das mindestens 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 beziehungsweise das korrigierte Paket deiner Distribution. Container müssen ebenfalls aktualisiert oder neu gebaut und mit der korrigierten Laufzeit gestartet werden. Ein Update der Anwendung allein reicht nicht: Prüfe die PHP-Version, die deine Webanfragen tatsächlich verarbeitet.
  3. Verlass dich nicht auf Konfigurationstricks. PHP nennt für einzelne Angriffswege Einstellungen, die das Risiko senken, aber keinen vollständigen allgemeinen Konfigurationsschutz. Nur das Update behebt die Lücken zuverlässig.
  4. Schotte ab, wo es kein Update gibt. CISA rät, nicht sofort patchbare Systeme vom Netz zu nehmen; das BSI empfiehlt, eine Trennung zu erwägen. Eine Web Application Firewall und Zugriffsbeschränkungen helfen als Übergang, ersetzen das Update aber nicht.
  5. Prüfe auf Einbruchsspuren. Amazon empfiehlt Untersuchungen ab mindestens dem 17. Oktober. Prüfe neben Zugriffen auch verdächtige Dateien und Prozesse. Fehlende Fehlermeldungen in den Logs sind laut PHP kein Nachweis, dass ein System sicher ist. Bei Anzeichen einer Kompromittierung reicht Patchen allein nicht: Lass den Vorfall untersuchen und erneuere betroffene Zugangsdaten, etwa Datenbank-Passwörter und API-Schlüssel, von einer bereinigten Umgebung aus.
  6. Schreib auf, welche Systeme kein Update bekommen können. Diese Liste ist die Grundlage für alles, was nach dem Notfall kommt.

Warum fehlender Support das Problem verschärft

Für eine unterstützte PHP-Version ist das Update der direkte Weg, die Lücken zu schließen. Bei PHP 7 oder 8.1 fehlt ein reguläres Release des PHP-Projekts. Es können aber Quellcode-Korrekturen oder Pakete der Distribution und des Hosters verfügbar sein: teils regulär, teils im erweiterten Support. Prüfe daher zuerst den konkreten Anbieter, bevor du von einem nicht mehr patchbaren System ausgehst.

Wie verbreitet ältere Zweige sind, zeigt die Auswertung von Modat mit Scan-Daten vom 20. Oktober: 4.384.302 PHP-Dienste auf 1.886.612 Hosts. Von den Diensten, deren PHP-Version sich auslesen ließ, liefen rund 3,47 Millionen beziehungsweise 79 Prozent auf einem Zweig, den PHP nicht mehr unterstützt, also 4.x, 5.x, 7.x, 8.0 oder 8.1. Das beschreibt den Scanbestand, nicht alle Websites weltweit. Modat betont, dass das keine Verwundbarkeit jedes einzelnen Dienstes belegt. Ob ein Anbieter die Lücken per Backport geschlossen hat, zeigt die Versionsnummer ohnehin nicht.

Das BSI empfiehlt grundsätzlich den Wechsel auf eine noch unterstützte PHP-Version: Alle Zweige vor 8.2 haben das Lebensende beim PHP-Projekt erreicht, und auch PHP 8.2 bekommt dort nur noch bis Jahresende Sicherheitsupdates.

Und die nächsten Termine stehen schon fest:

  • 31. Dezember 2026: Laut php.net endet der Sicherheits-Support des PHP-Projekts für PHP 8.2. PHP 8.3 folgt Ende 2027, PHP 8.4 Ende 2028.
  • Hoster stellen teils früher um. Host Europe etwa stellt PHP 8.2 auf seiner Classic-Hosting-Plattform laut eigener Ankündigung am 9. November 2026 vorab auf PHP 8.4 um und schaltet PHP 8.2 am 7. Dezember endgültig ab.
  • Alte Versionen kosten teils extra. IONOS nennt für seinen PHP Extended Support je nach Version 7,81 Euro (PHP 8.1) bis 27,36 Euro (PHP 4) im Monat inklusive Mehrwertsteuer. Welche Versionen verfügbar sind, hängt vom Vertrag ab: PHP 4 gibt es laut Hilfe-Center nur noch in älteren Verträgen.

Nach dem Patch: welche Wege es für alte PHP-Systeme gibt

Wenn ein System kein Update mehr bekommen kann, gibt es im Kern vier Wege. Sie lassen sich kombinieren, und keiner ist immer der richtige.

1. Innerhalb von PHP aktualisieren

Das ist die erste Option, die du prüfen solltest, wenn die Fachlogik und das Datenmodell noch passen. Werkzeuge wie Rector automatisieren bekannte Codeänderungen von alten auf neue PHP-Versionen. PHPStan hilft bei der statischen Codeanalyse, PHPCompatibility bei der Prüfung auf Versionsunverträglichkeiten.

Einfach ist das nicht immer. Auf dem Weg von PHP 5 zu 8 sind ganze Erweiterungen entfallen. PHP 8 hat außerdem geändert, wie Zahlen und Zeichenketten verglichen werden. Je nach Code kann das Berechnungen und Verzweigungen in der Geschäftslogik beeinflussen, nicht nur die Syntax. Ein automatisches Werkzeug beweist nicht, dass sich das System danach gleich verhält. Dafür brauchst du Tests, die altes und neues Verhalten vergleichen.

2. Mit Langzeitsupport überbrücken

Hoster und spezialisierte Anbieter liefern Sicherheitskorrekturen für alte PHP-Versionen nach, häufig gegen Gebühr. Das kann Zeit kaufen, wenn eine Umstellung noch nicht fertig ist. Lass dir konkret bestätigen, dass dein Paket beide PHP2Shell-Lücken schließt. Der Schutz hängt davon ab, was der Anbieter pflegt und wie schnell er liefert. Und ein gepatchtes PHP schließt keine Lücken im Shop, im CMS oder im eigenen Code, die selbst keine Updates mehr bekommen.

3. Auf Standardsoftware wechseln

Wenn die Abläufe weitgehend Standard sind, kann ein aktuelles Shopsystem oder eine SaaS-Lösung der richtige Weg sein. Für Magento 1 endete die Herstellerpflege im Juni 2020, für Shopware 5 laut Shopware Ende Juli 2024. Shopware-5-Plugins lassen sich nicht unverändert in Shopware 6 weiterverwenden; für Funktionen können aber Nachfolger-Erweiterungen bereitstehen. Daten lassen sich mit Migrationswerkzeugen übertragen. Eigene Preis-, Rabatt- und Versandregeln sowie Schnittstellen musst du einzeln prüfen: Was übernimmt das Zielsystem, was lässt sich übertragen, was muss neu umgesetzt oder aufgegeben werden?

4. Neu bauen, auch mit anderen Technologien

Manchmal ist das alte System so mit veraltetem Code, Bibliotheken und Sonderwegen verwachsen, dass ein Neubau günstiger sein kann als die Sanierung. Das muss ein Vergleich für dein System zeigen. Dann stellt sich auch die Frage nach der Technologie. Next.js mit TypeScript ist eine Option: Das Framework unterstützt TypeScript direkt und dokumentiert Werkzeuge für automatisierte Tests. Ob es passt, hängt von Anwendung, Team und Betrieb ab.

Ein deutsches Beispiel ist trivago. Das Unternehmen hat sein Web-Frontend von einer großen PHP-Codebasis und einem selbst entwickelten JavaScript-Framework auf Next.js mit TypeScript umgestellt. Laut seinem Erfahrungsbericht von 2022 sank das übertragene Seitengewicht der Ergebnisseite um rund 37 Prozent; zehn Releases am Tag wurden üblich statt ein oder zwei. Das ist kein allgemeiner Geschwindigkeits- oder Kostennachweis für einen Technologiewechsel. trivago beschreibt auch die andere Seite: Das Projekt lief von April 2020 bis Ende 2021, das Web-Team wuchs auf 30 Entwickler, die Weiterentwicklung neuer Funktionen stand lange praktisch still, und fehlende Optimierungen kosteten anfangs Umsatz.

Zwei Dinge gehören deshalb zur ehrlichen Einordnung. Erstens: Auch neue Technologien haben Lücken. Am selben 21. Oktober hat Node.js, eine Laufzeitumgebung für den Serverbetrieb von Next.js, Sicherheitsupdates für zehn Lücken veröffentlicht. Entscheidend ist, ob ein System Updates bekommt und ob jemand sie einspielen kann. Zweitens: „PHP ist alt“ ist kein Grund für einen Wechsel, denn PHP hat gepflegte Versionen. Ein Wechsel kann sinnvoll sein, wenn die Anwendung ohnehin neu gedacht werden muss, wenn das Team mit der neuen Technologie besser arbeiten kann oder wenn neue Anforderungen mit dem alten System nicht mehr umsetzbar sind.

Ein Neubau lässt sich auf die tatsächlich benötigten Funktionen begrenzen und neben dem Altsystem aufbauen; die Daten werden migriert, bevor das alte System abgeschaltet wird. Ob es währenddessen am Netz bleiben darf, hängt von seiner Absicherung ab; ein Migrationsplan ersetzt weder Patch noch nötige Abschottung. Entscheidend ist weniger die Programmiersprache als die Fachlogik. Wer vorher nicht festhält, welche Regeln das alte System tatsächlich anwendet, riskiert, sie falsch nachzubauen oder zu vergessen.

Welcher Weg passt?

  • Die Anwendung läuft gut, nur die PHP-Version ist alt: aktualisieren.
  • Die Entscheidung braucht noch Zeit, das System ist geschäftskritisch: mit Langzeitsupport überbrücken, aber mit Enddatum.
  • Die Abläufe sind Standard, die Software ist ein Shop oder ein CRM von der Stange: Standardsoftware prüfen.
  • Das System kann kein Update mehr bekommen, niemand kennt es mehr richtig, und es bildet Abläufe ab, die euch vom Wettbewerb unterscheiden: Ablösung durch eine neue Anwendung planen.

Wo AthenaRun hier steht

Wir lösen Altsysteme am Lebensende ab, also ERP-, Branchen- oder Eigensysteme, die keine Updates mehr bekommen, durch Individualsoftware. Nach einem kostenfreien Assessment definieren wir im Workshop die Zielprozesse, das Datenmodell und den Migrationsplan. Danach entsteht die neue Anwendung parallel zum Altsystem. Typischerweise ist sie nach vier bis acht Wochen produktiv, und das Altsystem läuft weiter, bis die Ablösung abgeschlossen ist, vorausgesetzt, es lässt sich bis dahin sicher betreiben. Wie das im Einzelnen abläuft, steht auf der Seite Altsystem ablösen.

Nicht jedes PHP-System muss abgelöst werden. Wenn du ein System hast, bei dem du nach PHP2Shell nicht weißt, ob Update, Überbrückung oder Ablösung der richtige Weg ist: Erstgespräch anfragen. Wir schauen uns die Lage mit dir an und sagen dir auch, wenn ein Update reicht.

Weiterlesen im Wissen-Hub

Mit welchen Kosten du bei einer Ablösung rechnen solltest, steht in Was kostet die Ablösung eines Altsystems ungefähr?. Wenn der Hersteller deiner Software den Support einstellt, zeigt Hersteller stellt die Branchensoftware ein: welche Alternativen du hast die Optionen. Und wie du bei einer veralteten Serverplattform entscheidest, liest du in Deine Branchensoftware läuft nur auf Windows Server 2016: drei Wege und was sie kosten.