PHP2Shell: Zwei kritische PHP-Lücken, kein Patch für alte Versionen

PHP veröffentlicht am 21. Oktober 2026 um 16:00 Uhr MESZ ein außerplanmäßiges Sicherheitsupdate für zwei kritische Lücken, die unter dem Namen PHP2Shell kursieren und laut dem Sicherheitsunternehmen watchTowr das Ausführen von Code aus der Ferne erlauben. Den Fix gibt es nur für die vier unterstützten Branches 8.2 bis 8.5. Nach einer Zählung des Sicherheitsunternehmens Mallory läuft mehr als die Hälfte der PHP-Server, die ihre Version im Internet anzeigen, auf einer älteren.

Was ist PHP2Shell?

PHP2Shell ist der inoffizielle Name für zwei kritische Schwachstellen in der Skriptsprache PHP, die unter den Kennungen CVE-2026-109618 und CVE-2026-109619 geführt werden. Laut watchTowr ermöglichen beide Remote Code Execution, also das Ausführen eigener Befehle auf dem Server über das Netz. Das PHP-Sicherheitsteam bewertet beide mit CVSS 9.2 nach Version 4.0. Laut W3Techs nutzen 69 Prozent aller Websites mit bekannter Serversprache PHP, etwa unter WordPress, Magento oder Shopware.

Öffentlich wurden die Lücken durch ein Leak: Am 20. Oktober kündigte ein Beitrag im Forum Hacker News zwei PHP-Lücken mit CVSS 10.0 an, betroffen seien alle Versionen ab PHP 5. Einen Beleg außer dem Vertrauen in seine Quelle hatte der Verfasser nach eigener Aussage nicht. watchTowr bestätigte, dass die Lücken echt sind und bis Donnerstag, 22. Oktober, unter Embargo standen, und gab an, CVE-2026-109618 nach eigener Einschätzung reproduziert zu haben. Um 19:33 Uhr UTC zog PHP mit einer Vorankündigung nach und legte das Release einen Tag vor. Kennungen und Versionsangabe stammen aus dem Leak; PHPs Notiz nennt beides nicht.

Was über PHP2Shell bekannt ist und was nicht

Bestätigt ist bisher nur, was PHP selbst angekündigt hat. Stand 21. Oktober 2026, vor dem Release um 16:00 Uhr MESZ:

• Von PHP bestätigt: zwei kritische Lücken mit CVSS 9.2 (v4.0), Release am 21. Oktober um 14:00 Uhr UTC, früher, falls Details öffentlich werden oder Angriffe auftauchen.
• Unbestätigt: betroffene Versionen und ob ein Angriff eine Betriebsart wie PHP-FPM oder CGI oder eine Anmeldung voraussetzt. Die Analyse mehrerer Sicherheitsforscher deutet auf die Funktion Session Upload Progress; PHP selbst nennt die Komponente nicht.
• Ausnutzung: keine bekannt. Huntress beobachtete bis zum 20. Oktober keine Angriffe und kennt keinen öffentlichen Exploit-Code; im CISA-KEV-Katalog stehen die Lücken nicht.
• Abhilfe vor dem Patch: PHP nennt keine offizielle. Als Zwischenlösung empfehlen Sicherheitsforscher, Session Upload Progress zu deaktivieren (siehe nächster Abschnitt); die Maßnahme folgt aus der Analyse des geleakten Fehlers und schließt möglicherweise nur eine der beiden Lücken.

Nach dem Release wird es schnell gehen. Mit dem Update wird der korrigierte Quellcode öffentlich, und der Vergleich mit der Vorversion zeigt, wo die Lücke saß. Als CVE-2024-4577, eine PHP-Lücke im CGI-Modus unter Windows, im Juni 2024 bekannt wurde, sah Akamai binnen 24 Stunden Angriffsversuche auf seinen Honeypots.

Sofortmaßnahme vor dem Patch: Session Upload Progress abschalten

Wer nicht sofort patchen kann oder auf einer End-of-Life-Version festsitzt, kann die mutmaßlich betroffene Funktion deaktivieren. Mehrere Sicherheitsforscher, darunter Flatt Security und J4ck3LSyN, führen die Lücken auf PHPs Session Upload Progress zurück. Die Funktion verarbeitet ein Feld namens PHP_SESSION_UPLOAD_PROGRESS in multipart/form-data-Uploads und ist standardmäßig aktiv. Dieses Feld setzt der Absender der Anfrage, nicht die Anwendung; der Code läuft also auch, wenn eine Seite nie eine Fortschrittsanzeige eingebaut hat. CERT-EU stuft die Lücken als möglicherweise unauthentifizierte Remote Code Execution ein.

Abschalten per php.ini oder Pool-Konfiguration, danach PHP-FPM beziehungsweise Apache neu starten:

session.upload_progress.enabled = 0

Für die Umsetzung zählt der Ort der Einstellung:

• Mit ini_set() im PHP-Code lässt sie sich nicht ändern. Sie gehört in die php.ini, bei CGI/FastCGI in die .user.ini (bis zu fünf Minuten gecacht, user_ini.cache_ttl) oder unter dem Apache-Modul per php_flag session.upload_progress.enabled off in die .htaccess.
• Nur die Fortschrittsanzeige entfällt; Uploads selbst funktionieren weiter. Der Eingriff ist in den meisten Anwendungen folgenlos.
• Prüfen Sie die aktive Einstellung über eine phpinfo()-Seite und löschen Sie diese danach wieder.
• Wo die php.ini nicht erreichbar ist, kann eine Web Application Firewall als zweite Schicht multipart/form-data-Anfragen mit dem Feld PHP_SESSION_UPLOAD_PROGRESS melden oder blocken. Erst im Melde-Modus testen: Anwendungen mit echter Fortschrittsanzeige senden dieses Feld regulär.

Die Zwischenlösung ersetzt den Patch nicht. Flatt Security bezeichnet sie als wahrscheinlich, aber nicht garantiert wirksam; J4ck3LSyN vermutet, dass sie nur eine der beiden Lücken schließt und die zweite im Multipart-Parser sitzt. CERT-EU nennt die Einstellung nicht und rät, nicht sofort patchbare, aus dem Internet erreichbare Anwendungen bis zum Fix zu isolieren.

Warum ältere PHP-Versionen keinen Patch bekommen

PHP liefert Sicherheitsupdates nur für unterstützte Branches, derzeit 8.2 bis 8.5. PHP 8.1 und älter hat das Ende der Laufzeit erreicht; reichen die Lücken dorthin zurück, gibt es vom Hersteller keinen Fix.

Wie viele Systeme das betrifft, hat Mallory am 20. Oktober anhand öffentlich sichtbarer HTTP-Banner gezählt: Mehr als 880.000 aus dem Internet erreichbare Hosts meldeten PHP 8.1 oder älter, 59 Prozent der rund 1,5 Millionen Hosts mit Versionsangabe. Rund 740.000 weitere zeigten PHP ohne Version. Im deutschsprachigen Raum liegt der Anteil ohne Fix laut Mallory bei 41 Prozent in Deutschland, 53 Prozent in Österreich und 64 Prozent in der Schweiz.

Die Zahlen beschreiben Banner, keine bestätigt verwundbaren Systeme; Distributionen wie Debian, Ubuntu oder Red Hat portieren Korrekturen teils auf ältere Pakete zurück. Auch 8.2 ist nur auf Zeit versorgt: Sicherheitsupdates gibt es bis Ende 2026. Wer heute einen 8.2-Server patcht, plant das Upgrade gleich mit ein.

Was hilft – und warum Sichtbarkeit entscheidet

Die Vorbereitung bis zum Release folgt im Kern dem Rapid-Response-Beitrag von Huntress und der Warnung von CERT-EU:

1. Inventar erstellen: jede PHP-Installation erfassen, auch in Appliances, Windows-Software und Control Panels wie cPanel oder Plesk. Wer den Webserver nicht selbst betreibt, klärt mit dem Hoster, wann dieser aktualisiert.
2. Ab 16:00 Uhr MESZ aktualisieren: aus dem Internet erreichbare Systeme zuerst, zurückportierte Pakete von Distribution und Hoster prüfen.
3. End-of-Life-Systeme absichern: auf einen unterstützten Branch wechseln, vom Netz nehmen oder hinter VPN oder Web Application Firewall stellen. CERT-EU rät, Anwendungen, die sich nicht sofort patchen lassen, bis zum Fix vom öffentlichen Netz zu isolieren.
4. Prozesse überwachen: Alarm, wenn php-fpm, php-cgi, httpd oder apache2 eine Shell, einen Interpreter oder Werkzeuge wie curl, wget oder certutil.exe startet.
5. Bei Verdacht isolieren: Server trennen, Webserver- und PHP-Logs sichern, nach Webshells, neuen Dateien im Webroot, Cronjobs, geplanten Tasks und Konten suchen.

Am Tag des Updates ist selten das Aktualisieren das Problem, sondern die Frage, wo überall PHP läuft. blacklens.io erfasst über Attack Surface Management laufend von außen, welche Domains, Dienste und Webanwendungen erreichbar sind und welche Technologien darauf laufen; interne Systeme deckt der Sentry Agent ab. Sobald die CVE-Einträge mit Produktangaben vorliegen, gleicht das Threat Center sie in Echtzeit mit diesem Inventar ab und zeigt, ob ein Treffer auf der exakten Version beruht oder nur auf dem Produkt, etwa weil ein Server seine Version verbirgt. Ohne Prüfvorlage für einen Verifikationsscan markiert es den Treffer zur manuellen Prüfung. Was ein PHP-Prozess auf dem Server startet, sieht blacklens.io nicht; das bleibt Aufgabe der Überwachung auf dem Host.