Eine PHP-Sicherheitslücke namens „PHP2Shell“ hält seit dem 20. Oktober 2026 Betreiber von Websites, Onlineshops und Webanwendungen weltweit in Atem. Zwei kritische Schwachstellen im Kern der Programmiersprache erlauben es Angreifern, ohne Anmeldung eigenen Code auf Webservern auszuführen. Das PHP-Projekt hat am 21. Oktober 2026 Sicherheitsupdates veröffentlicht, das BSI rät zur sofortigen Installation. Für viele mittelständische Unternehmen beginnt das eigentliche Problem allerdings eine Stufe früher: Wo läuft im eigenen Betrieb überhaupt PHP?
Was ist die PHP-Sicherheitslücke PHP2Shell?
PHP2Shell ist der Sammelname für zwei kritische Schwachstellen in PHP selbst, registriert als CVE-2026-109618 und CVE-2026-109619. Das PHP-Sicherheitsteam bewertet beide nach CVSS 4.0 mit 9,2 von 10 Punkten. CVSS (Common Vulnerability Scoring System) ist der Standard, mit dem die Schwere von Sicherheitslücken vergleichbar eingestuft wird. Laut BSI lässt sich aus der Bewertung ableiten, dass Angreifer weder ein Benutzerkonto noch die Mitwirkung eines Nutzers benötigen.
Technisch handelt es sich um Fehler in der Speicherverwaltung. Die erste Lücke betrifft den Umgang mit Speichermangel: Bricht PHP eine Anfrage deshalb ab, bleiben interne Daten halb eingerichtet zurück und werden beim Aufräumen trotzdem als gültig behandelt. Bei der zweiten Lücke überdauern Zustandsdaten einer Anfrage die Freigabe ihres Speichers. Verarbeitet derselbe Prozess später eine neue Anfrage, greift PHP auf diese veralteten Daten zu.
Beide Fehler führen im schlimmsten Fall zu Remote Code Execution (RCE). Gemeint ist, dass ein Angreifer aus der Ferne beliebige Befehle auf dem Server ausführen kann. Er arbeitet dann mit den Rechten des Webserver-Kontos. Damit kann er Inhalte verändern, Kundendaten auslesen oder eine dauerhafte Hintertür einrichten.
Warum dieser Fall ernster ist als ein gewöhnliches Update
Die PHP-Sicherheitslücke ist kein Fehler in einem einzelnen Plugin, sondern im Fundament. Das unterscheidet PHP2Shell von den üblichen Meldungen über verwundbare WordPress-Erweiterungen. Der Name spielt laut BSI bewusst auf Log4Shell an, eine Schwachstelle, an die sich viele IT-Verantwortliche noch gut erinnern.
Hinzu kommt der Ablauf. Nach Darstellung des Sicherheitsunternehmens Huntress tauchten Details am Morgen des 20. Oktober in einem Beitrag auf Hacker News auf, bevor die koordinierte Veröffentlichung stattfinden sollte. Der Beitrag wurde gelöscht, Screenshots verbreiteten sich trotzdem. Die Sicherheitsforscher von watchTowr bestätigten die Echtheit und konnten eine der beiden Lücken nachstellen. Das PHP-Projekt zog seine Updates daraufhin um einen Tag vor.
Zur Einordnung gehört auch, was bislang nicht passiert ist. Das BSI kannte in seiner Warnung vom 21. Oktober 2026 keine bestätigten Angriffe, verweist aber auf unbestätigte Berichte über funktionierende Exploits. Huntress hatte bis zum Vormittag desselben Tages (US-Ostküstenzeit) in den betreuten Umgebungen keine Ausnutzung beobachtet. Andere Stellen berichten nach Angaben von Huntress jedoch bereits von ersten Angriffen.
Wie ernst Behörden die Lage nehmen, zeigt ein Beispiel aus Rheinland-Pfalz. Laut einer dpa-Meldung in der Deutschen Handwerks Zeitung hat die Landeshauptstadt Mainz ihr Webportal mainz.de und mehrere Online-Dienste vorsorglich abgeschaltet. Auch andere Kommunen, Behörden, Hochschulen und Krankenhäuser nahmen Angebote vorübergehend vom Netz.
Welche Systeme im Unternehmen betroffen sind
Von der PHP-Sicherheitslücke betroffen ist grundsätzlich jede PHP-Installation, die Webanfragen beantwortet. Das PHP-Projekt nennt ausdrücklich PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed, also praktisch alle gängigen Betriebsarten. Das höchste Risiko sieht das PHP-Team bei mod_php. Dort existiert ein nachgewiesener Angriff, der greift, bevor die eigentliche Anwendung überhaupt startet.
Diese Details sind für Entscheider wichtig. Ein sauber gepflegtes WordPress mit aktuellen Plugins schützt hier nicht. Die PHP-Sicherheitslücke liegt unterhalb der Anwendung, und nur die Laufzeitumgebung selbst kann sie schließen.
Die offensichtlichen Kandidaten
Die Firmenwebsite steht meist ganz oben auf der Liste. Dazu kommen Onlineshops, Kunden- und Bewerberportale, Buchungssysteme, Intranets und Wikis. Huntress nennt ausdrücklich WordPress, Drupal, Joomla und Magento sowie Shared-Hosting-Plattformen.
Bei gemieteten Hosting-Paketen aktualisiert in der Regel der Hoster die PHP-Umgebung. In vielen Betrieben zeigt sich allerdings ein typisches Muster: Im Kundenmenü ist aus Kompatibilitätsgründen eine ältere PHP-Version fest eingestellt, oft für ein altes Theme oder eine selbst entwickelte Erweiterung. Ob diese Version überhaupt noch Updates erhält, prüft dann niemand.
Die versteckten PHP-Installationen
Schwieriger wird es bei Systemen, die nicht nach Webserver aussehen. Huntress weist darauf hin, dass PHP in vielen Herstellerprodukten steckt, ohne dass es nach außen sichtbar ist. Genannt werden Appliances, Windows-Software mit mitgelieferter php.exe oder php-cgi.exe sowie Verwaltungsoberflächen wie cPanel und Plesk.
Für den Mittelstand heißt das: Auch Fachanwendungen mit Browser-Oberfläche, Verwaltungskonsolen von Geräten oder ältere Eigenentwicklungen gehören auf die Prüfliste. Hier liefert nicht das PHP-Projekt das Update, sondern der jeweilige Hersteller. Bis dessen Fix vorliegt, bleibt nur die Abschottung vom Internet.
Welche PHP-Versionen die PHP-Sicherheitslücke schließen
Die Lücken sind in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 behoben. Alle vier Versionen erschienen am 21. Oktober 2026. Linux-Distributionen und Anbieter mit Langzeitunterstützung haben die Korrekturen vorab erhalten. Wer PHP über die Paketverwaltung bezieht, sollte deshalb zuerst dort nach aktualisierten Paketen schauen.
PHP 8.1 und ältere Versionen erhalten vom PHP-Projekt keine Updates mehr. Manche Distributionen liefern trotzdem nachgezogene Korrekturen. Angesichts der Schwere hat das PHP-Team zudem minimale Quelltext-Korrekturen für PHP 7.4, 8.0 und 8.1 bereitgestellt. Sie richten sich an Betreiber, die PHP selbst kompilieren. Eine Dauerlösung ist das nicht.
Einen Sonderfall nennt das PHP-Projekt ebenfalls. Das ehrenamtlich gepflegte Paketquellen-Angebot rpms.remirepo.net hatte am Veröffentlichungstag keine Updates. Betreiber, die darauf setzen, sollen auf Pakete der Distribution wechseln oder PHP selbst bauen.
Nach dem Update gilt: PHP-Prozesse und Webserver neu starten und die aktive Version kontrollieren. Ein eingespieltes Paket, das noch nicht geladen ist, schützt nicht. Zudem endet die Sicherheitsunterstützung für PHP 8.2 am 31. Dezember 2026. Wer dort steht, sollte den Wechsel auf eine neuere Version direkt mit einplanen.
Was Notmaßnahmen leisten und was nicht
Notmaßnahmen senken das Risiko durch die PHP-Sicherheitslücke, ersetzen das Update aber nicht. Das PHP-Projekt stellt klar, dass es keine vollständige Absicherung über Konfiguration gibt und nur die Aktualisierung sicher ist. Die empfohlenen Einstellungen versperren lediglich bestimmte bekannte Angriffswege.
Gegen die erste Lücke empfiehlt das PHP-Projekt, das PHP-Speicherlimit administrativ auf unbegrenzt zu setzen (memory_limit=-1) und die maximale Größe von Formulardaten niedrig zu halten. Konkret nennt es 8 MB ohne Datei-Uploads und 32 MB mit Uploads. Ein Speicherlimit auf Ebene von Container oder cgroup kann dann die Verfügbarkeit absichern. Gegen die zweite Lücke hilft das Abschalten der Upload-Fortschrittsanzeige in Sessions (session.upload_progress.enabled=0) mit anschließendem Neustart aller PHP-Prozesse. Unter PHP 8.5 kommt fatal_error_backtraces=0 hinzu.
Für Systeme mit nicht mehr unterstützter PHP-Version rät Huntress zu einem klaren Schritt. Sie sollten vom Internet getrennt oder hinter VPN oder Web Application Firewall gestellt werden, bis ein Upgrade erfolgt ist. Eine Web Application Firewall (WAF) filtert Anfragen an Webanwendungen und kann bekannte Angriffsmuster abfangen.
Wurde der Server bereits angegriffen? Anzeichen und Erstreaktion
Ein Update schließt die Lücke, entfernt aber keinen Angreifer, der schon im System ist. Zwischen dem Leak am 20. Oktober und dem Einspielen des Patches liegt bei vielen Systemen ein Zeitfenster. Deshalb gehört zur Reaktion auf die PHP-Sicherheitslücke auch ein kurzer Blick nach hinten.
Huntress beschreibt, woran sich eine Ausnutzung typischerweise zeigt. PHP-Prozesse starten Programme, die sie normalerweise nie aufrufen: Kommandozeilen wie bash oder PowerShell, Skriptsprachen wie Python oder Download-Werkzeuge wie curl und wget. Auch Erkundungsbefehle wie whoami oder id, die direkt aus dem Webserver heraus laufen, sind ein Warnsignal.
Ein häufiges Ziel solcher Angriffe ist eine Webshell. Eine Webshell ist ein kleines Skript, das Angreifer auf dem Server ablegen, um ihn später jederzeit wieder fernzusteuern. Sie überlebt jedes PHP-Update, weil sie Teil der Website-Dateien ist.
Bei einem Verdacht empfiehlt Huntress, den Server zu isolieren und die Protokolle von Webserver und PHP zu sichern. Anschließend wird nach Webshells, neuen Dateien im Webverzeichnis, neuen zeitgesteuerten Aufgaben und neuen Benutzerkonten gesucht. Huntress weist zudem darauf hin, dass viele Linux-Webserver kaum überwacht werden. Genau dort können Angriffe lange unbemerkt bleiben.
Was Nichtstun kostet
Ein übernommener Webserver ist selten nur ein Imageproblem. Angreifer können Kundendaten aus Shop oder Portal abziehen, Schadcode an Besucher ausliefern oder den Server als Sprungbrett für weitere Angriffe nutzen. Hinzu kommen Ausfallzeiten, Wiederherstellungsaufwand und im Ernstfall Meldepflichten gegenüber der Datenschutzaufsicht.
Auch die Geschäftsführung ist gefragt. Liegt eine öffentliche Warnung des BSI vor, wird es im Schadensfall schwer, sich auf sorgfältiges Handeln zu berufen, wenn nichts passiert ist. Unser Beitrag zur Manager-Haftung bei Cyberangriffen zeigt, warum eine dokumentierte Reaktion hier mehr zählt als jede nachträgliche Erklärung.
Der Aufwand für die Vorsorge ist dagegen überschaubar. In den meisten Unternehmen geht es um wenige Systeme, eine Versionsprüfung und ein Update. Teuer wird es fast immer erst dann, wenn niemand genau weiß, welche Systeme betroffen sind.
Prüfliste: Die PHP-Sicherheitslücke strukturiert abarbeiten
Für Geschäftsführung und IT-Abteilung hat sich eine feste Reihenfolge bewährt. Sie verhindert, dass Systeme durchrutschen, und erzeugt nebenbei die Dokumentation für später.
- Inventar erstellen: Alle Systeme mit PHP erfassen, inklusive Hosting-Pakete, Shops, Portale, Fachanwendungen und Geräte mit Weboberfläche.
- Versionen prüfen: Für jedes System die aktive PHP-Version ermitteln und mit 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 abgleichen.
- Priorisieren: Aus dem Internet erreichbare Systeme zuerst aktualisieren, interne danach.
- Hoster einbinden: Bei gemieteten Paketen die eingestellte PHP-Version kontrollieren und den Stand beim Hosting-Anbieter schriftlich bestätigen lassen.
- Altversionen abschotten: PHP 8.1 und älter vom Netz nehmen oder hinter VPN beziehungsweise WAF stellen, Upgrade terminieren.
- Neustart und Kontrolle: PHP-Prozesse neu starten und die tatsächlich laufende Version prüfen.
- Spuren sichten: Protokolle sichern und auf ungewöhnliche Prozesse, neue Dateien und neue Konten prüfen.
- Dokumentieren: Festhalten, wer wann welches System geprüft und aktualisiert hat.
Wer diese Schritte nicht nur jetzt, sondern regelmäßig durchgeht, ist auf die nächste Warnung besser vorbereitet. Ein strukturierter Cyber-Sicherheits-Check liefert dafür die Grundlage, denn er macht auch die Systeme sichtbar, an die im Alltag niemand denkt.
Fazit: Inventar vor Panik
PHP2Shell ist eine ernste, aber beherrschbare Lage. Die Updates liegen vor, die Notmaßnahmen sind dokumentiert, und bestätigte Massenangriffe gab es zum Zeitpunkt der BSI-Warnung noch nicht. Entscheidend ist jetzt Tempo bei den Systemen, die aus dem Internet erreichbar sind.
Die eigentliche Lehre reicht über diese PHP-Sicherheitslücke hinaus. Unternehmen, die ihre Web-Systeme, Versionen und Zuständigkeiten kennen, erledigen solche Warnungen in Stunden. Wer erst suchen muss, verliert genau die Zeit, die Angreifer nutzen. Ein dauerhaft gepflegtes Systeminventar und klare Update-Prozesse gehören deshalb zu den Kernaufgaben der digitalen Sicherheit im Mittelstand.
DIGITALBÜRO LIMBURG – PHP-Lücken schließen, bevor Angreifer die Firmenwebsite übernehmen – denn We make IT easy & smart. 🚀
Jetzt unverbindlich prüfen lassen, ob Website, Shop und Webanwendungen Ihres Unternehmens von PHP2Shell betroffen sind, ob rund um Limburg oder bundesweit per Remote-Betreuung.
Weiterführende Quellen & Links
- BSI: PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit (Cybersicherheitswarnung, Version 1.0)
- PHP.net: Security advisory – Critical remote code execution vulnerabilities, update now
- PHP-Projekt auf GitHub: Advisory GHSA-w8hw-w9fx-j79w zu CVE-2026-109618
- Huntress: Rapid Response – php2shell, Leaked Critical PHP Vulnerabilities
- Deutsche Handwerks Zeitung: Gravierende Sicherheitslücke bedroht weltweit Webseiten