PHP2Shell: Warum plötzlich so viele Webseiten offline sind

Code

PHP2Shell: Warum plötzlich so viele Webseiten offline sind

Wer am Mittwochabend eine Stadtverwaltung, ein Krankenhaus oder einen Stadtwerke-Auftritt aufrufen wollte, stand vielerorts vor verschlossenen Türen. Die Charité nahm ihre Webseite vom Netz, ebenso die Städte Mainz und Saarbrücken, in den Niederlanden fielen DigiD und MijnOverheid aus. Der Grund hat einen Namen, der nach Hacker-Film klingt, aber bitterer Ernst ist: PHP2Shell.

Was passiert ist

Am 21. Oktober 2026 veröffentlichte das PHP-Team Notfall-Updates für zwei kritische Schwachstellen im Kern der Sprache selbst: CVE-2026-109618 und CVE-2026-109619, beide mit 9,2 von 10 Punkten bewertet. Laut CERT-EU können beide Lücken eine Codeausführung aus der Ferne ohne jede Anmeldung ermöglichen. Betroffen ist jede PHP-Installation, die Webanfragen bearbeitet, darunter Apache mit mod_php, PHP-FPM, php-cgi, FrankenPHP und LiteSpeed. Am gefährlichsten ist mod_php: Dort reicht laut PHP-Sicherheitshinweis eine einzige unauthentifizierte Anfrage, noch bevor der Code der eigentlichen Webseite überhaupt läuft.

Das ist der Punkt, den viele Betreiber unterschätzen: Der Fehler steckt nicht in WordPress, Drupal oder TYPO3, sondern in der Laufzeitumgebung darunter. Eine perfekt gepflegte Webanwendung nützt nichts, wenn der Unterbau offen steht. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stufte die Lage auf Warnstufe 3 von 4 („Orange“) ein und hielt eine großflächige Ausnutzung binnen weniger Stunden für wahrscheinlich, wie die ZFK berichtet.

Dass so viele Dienste abgeschaltet wurden, ist keine Panikreaktion, sondern Vorsicht: Die Abschaltungen bedeuten nicht automatisch, dass jemand eingebrochen ist. Das Schweizer Fernsehen SRF vermeldete am Mittwoch erste Angriffsversuche, bestätigte Einbrüche gab es zu diesem Zeitpunkt nicht. Pikant: Die Details waren vorab durchgesickert, weshalb das PHP-Team den Veröffentlichungstermin um einen Tag vorziehen musste.

Das eigentliche Problem: Hunderttausende Server ohne Fix

Besonders unbequem ist die Lage bei älteren Versionen. Offizielle Korrekturen gibt es nur für die Zweige 8.2 bis 8.5. Für PHP 8.1 und älter erscheint kein reguläres Update, obwohl das BSI Versionen bis mindestens PHP 5 für verwundbar hält. Nach einer von der ZFK zitierten Shodan-Auswertung laufen weltweit rund 884.000 erreichbare Server noch mit PHP 8.1 oder älter. Wer jahrelang „läuft doch“ gesagt hat, bekommt jetzt die Rechnung. Gerade Behörden, Schulen und kleine Vereine betreiben oft Webseiten, um die sich seit Jahren niemand mehr kümmert.

Für normale Besucherinnen und Besucher besteht kein Handlungsbedarf, Updates auf dem eigenen Rechner sind nicht nötig. Wachsam sollte man trotzdem bleiben: Malwarebytes warnt, dass vertrauenswürdige Seiten kurzzeitig nicht mehr vertrauenswürdig sein können. Bei unerwarteten Weiterleitungen, Downloads oder wiederholten Login-Aufforderungen gilt: Seite verlassen.

So aktualisieren Sie PHP richtig

1. Welche Version läuft eigentlich? Prüfen Sie auf dem Server mit php -v. Achtung: Bei Linux-Distributionen stecken Sicherheitskorrekturen oft in Paketen mit altem Versionsstring. Verlassen Sie sich deshalb nicht allein auf die Nummer, sondern suchen Sie im Changelog des Pakets nach den beiden CVE-Kennungen.

2. Auf eine gepatchte Version gehen. Die ersten korrigierten Versionen sind:

PHP-Zweig Erste sichere Version Sicherheitsunterstützung bis
8.5 8.5.12 31.12.2029
8.4 8.4.27 31.12.2028
8.3 8.3.36 31.12.2027
8.2 8.2.35 31.12.2026

Die Laufzeiten stammen aus dem offiziellen PHP-Supportplan. Wer ohnehin umstellen muss, sollte PHP 8.2 meiden, weil dessen Support in wenigen Wochen endet, und direkt auf 8.3, 8.4 oder 8.5 gehen. Dabei hilft der jeweilige Migrationsleitfaden, etwa für PHP 8.5.

3. Unter Debian und Ubuntu genügt in der Regel sudo apt update && sudo apt upgrade. Prüfen Sie danach den Changelog des PHP-Pakets auf die beiden CVEs.

4. Dienste neu starten. Ohne Neustart läuft der alte, verwundbare Interpreter weiter. Starten Sie Apache, PHP-FPM und alle langlebigen PHP-Prozesse neu.

5. Webhosting-Kunden können selbst meist nichts patchen. Fragen Sie beim Anbieter nach, ob die Korrektur tatsächlich installiert und nicht nur geplant ist. Ein WordPress-Update ersetzt das PHP-Update nicht.

6. Wer mit PHP 8.1 oder älter feststeckt, sollte den Anbieter nach einem Backport fragen oder auf eine unterstützte Version wechseln. Das PHP-Team hat zudem minimale Quellcode-Patches für 7.4, 8.0 und 8.1 bereitgestellt, gedacht für Betreiber, die selbst bauen oder keinen Langzeit-Supportanbieter haben. Nutzer des Remi-Repositorys sollten auf Distributionspakete wechseln oder selbst kompilieren, weil dort am Veröffentlichungstag keine Updates bereitstanden.

7. Notlösung, wenn es nicht sofort geht. Nur das Update behebt die Lücken vollständig. Als Überbrückung nennt das PHP-Team unter anderem session.upload_progress.enabled=0 in der php.ini, ein niedriges post_max_size sowie memory_limit=-1 in einer Weise, die Anwendungen nicht überschreiben können. Das schließt nicht alle Angriffswege. Wenn gar nichts anderes bleibt, rät CERT-EU, internetfähige Anwendungen zeitweise vom öffentlichen Netz zu trennen.

8. Nach dem Update prüfen. Ein Patch beweist nicht, dass der Server sauber ist. Kontrollieren Sie auf unbekannte oder veränderte PHP-Dateien, neue Administratorkonten und ungewöhnliche ausgehende Verbindungen. Auffällig sind außerdem gehäufte HTTP-500-Fehler und unerklärliche Neustarts von PHP-Prozessen.

Ein weiterer Hinweis vom 23. Oktober: Das PHP-Team empfiehlt, session.upload_progress.enabled=0 bis zum nächsten regulären Bugfix-Release gesetzt zu lassen, um einen unwahrscheinlichen weiteren Angriffsweg abzudecken. Wer es schon gesetzt hat, muss nichts weiter tun.

Mein Fazit

PHP2Shell zeigt, wie fragil ein Internet ist, das auf wenigen zentralen Bausteinen ruht, um die sich oft zu wenig Menschen kümmern. Dass Behörden ihre Portale vom Netz nehmen müssen, ist kein Zeichen von Hysterie, sondern von jahrelang aufgeschobener Wartung. Wer Verantwortung für Server trägt, sollte Inventur machen: Welche Systeme laufen, welche PHP-Version steckt darunter, wer ist zuständig? Open-Source-Software hat den Vorteil, dass Fehler öffentlich dokumentiert und schnell behoben werden. Das setzt aber voraus, dass die Updates auch eingespielt werden.

Quellen: CERT-EU Security Advisory 2026-018, PHP.net News-Archiv 2026, PHP.net Supported Versions, Malwarebytes, ZFK, SRF, The Hacker News

Siehe auch