Das PHP-Sicherheitsteam kündigte zwei kritische Schwachstellen im Interpreter selbst an, nicht in einem Framework oder Plugin. Die Fehler tragen die Kennungen CVE-2026-109618 und CVE-2026-109619 und werden zusammen PHP2Shell genannt. PHP bewertete sie mit 9,2 nach CVSS v4.0. Frühe Leaks nannten 10,0, doch dieser Wert war nicht bestätigt.

php.ini
session.upload_progress.enabled = 0

CERT-EU bezeichnete die Auswirkung in Advisory 2026-018 als unauthentifizierte Remote Code Execution. CERT-EU und die australische ACSC hielten PHP 5 und neuere Versionen für potenziell betroffen. Eine offizielle Liste betroffener Versionen lag zum Redaktionsschluss noch nicht vor. Die geplanten Fixes betrafen PHP 8.2, 8.3, 8.4 und 8.5. Vorabberichte nannten 8.5.12, 8.4.27, 8.3.36 und 8.2.35, vorbehaltlich der Bestätigung durch die offizielle Veröffentlichung.

Die Veröffentlichung lief nicht nach dem üblichen Embargo-Modell. Gegen 15:20 UTC am 20. Oktober warnte ein anonymer Beitrag auf Hacker News vor der bevorstehenden Veröffentlichung zweier kritischer PHP-RCE-Fehler. Der Beitrag wurde gelöscht, Screenshots verbreiteten sich jedoch weiter. Das ursprüngliche Embargo sollte laut Bericht bis zum 22. Oktober laufen. PHP zog die Veröffentlichung daraufhin auf den 21. Oktober um 14:00 UTC vor und behielt eine noch frühere Veröffentlichung bei aktiver Ausnutzung als Option. CERT-EU veröffentlichte Advisory 2026-018, watchTowr reproduzierte einen Fehler, und ein kurzes Demovideo eines Forschers wurde später entfernt.

Frühe Analysen verorteten das Problem im Session-Upload-Progress-Code von PHP. GMO Flatt Security erklärte um 05:00 UTC, dass die online verbreitete Konfigurationsänderung keinen vollständigen Schutz biete und voraussichtlich umgangen werde. Um 07:43 UTC meldete Cloudflare-CTO Dane Knecht erste Angriffe. Cloudflare aktivierte dafür Notfallregeln in der WAF für alle Kunden, einschließlich der kostenlosen Tarife. Huntress, watchTowr und die ACSC hatten zum Zeitpunkt ihrer Beiträge keine bestätigte Ausnutzung in freier Wildbahn gemeldet.

Innerhalb weniger Stunden erschienen Proof-of-Concept-Repositories auf GitHub. Einige dienten der Prüfung, andere behaupteten, vollständige Exploits zu enthalten. Mindestens eine unabhängige Prüfung kam zu dem Ergebnis, dass der kursierende Exploit-Code nicht funktionierte. Nach der Veröffentlichung eines Fixes können Angreifer den korrigierten Code direkt mit der verwundbaren Version vergleichen. Sansec erwartete deshalb Massenangriffe innerhalb von Minuten nach der Veröffentlichung.

Der vermutete Angriffsweg liegt in der Verarbeitung von Multipart-Formulardaten durch die PHP-Laufzeit. Diese Daten werden bei Datei-Uploads verwendet und verarbeitet, bevor der Anwendungscode startet. Falls diese Einschätzung zutrifft, kommen Login-Prüfungen, CSRF-Schutz und die Validierung von Uploads zu spät. Das Abschalten von PHP-Datei-Uploads verhindert die Verarbeitung eines Multipart-Requests möglicherweise nicht. Damit könnte jede Seite mit POST-Annahme relevant sein, nicht nur ein Upload-Formular. PHP hatte die genaue Ursache nicht bestätigt, und Forscher waren sich über die betroffene Komponente uneinig. Die übereinstimmende Empfehlung lautete, PHP zu patchen oder zu aktualisieren.

Als Workaround verbreitete sich `session.upload_progress.enabled = 0`. GMO Flatt erklärte später, dass diese Änderung keinen vollständigen Schutz darstellt. Ein anderer Forscher hielt die zweite Schwachstelle unabhängig von dieser Option über den Multipart-Parser erreichbar. Joe Ferguson, Release Manager von PHP 8.6, warnte ebenfalls vor Vertrauen in INI-Einstellungen. Die Option ist PHP_INI_PERDIR und kann daher nicht zur Laufzeit mit `ini_set()` geändert werden. Eine Änderung in der CLI-Konfiguration statt im PHP-FPM-Pool oder in `.user.ini` unter mod_php kann wirkungslos bleiben. Das Abschalten entfernt die Upload-Fortschrittsanzeige und kann eine zusätzliche Schutzschicht bilden, beendet den Vorfall aber nicht.

Besonders groß ist die Lücke bei nicht mehr unterstützten Zweigen. PHP 8.1 erreichte im Dezember 2025 sein Ende, PHP 8.0 im November 2023. PHP 7.x und 5.x waren bereits früher ausgelaufen. Falls die Schwachstellen tatsächlich bis PHP 5 zurückreichen, erhalten diese Installationen keinen Fix vom PHP-Projekt. Eine Shodan-Auswertung von Mallory fand am 20. Oktober rund 1,5 Millionen internetseitig erreichbare Hosts, die eine PHP-Version bekanntgaben. Etwa 884.000 davon, also 59 Prozent, liefen auf einem Zweig ohne geplanten Fix. Davon entfielen ungefähr 369.000 auf PHP 5.x, 329.000 auf 7.x und 186.000 auf 8.0 oder 8.1. Weitere 740.000 Hosts verbargen ihre Version. Die tatsächliche Zahl dürfte daher höher liegen. Banner-Zählungen sind keine Zählung verwundbarer Systeme.

Für Indien wies dieselbe Auswertung etwa 53.600 PHP-Hosts aus. Rund 19.800 der Hosts mit sichtbarer Versionsnummer liefen auf einem Zweig ohne geplanten Fix. Die Banner-Daten nennen keine Betreiber. Zu den alten Installationen gehören häufig verlassene Portale, kleine Unternehmensseiten und jahrelang unveränderte Shared-Hosting-Systeme.

Betreiber eines ausgelaufenen Zweigs haben vier realistische Optionen. Sie können auf eine unterstützte PHP-Version wechseln, einen Backport vom Linux-Anbieter oder Hoster beziehen, das System hinter VPN oder Allowlist aus dem öffentlichen Netz nehmen oder es abschalten. Enterprise-Distributionen und einzelne Hoster pflegen alte Pakete nach eigenen Zeitplänen. Maßgeblich ist deshalb die CVE im Advisory des Anbieters, nicht nur die PHP-Versionsnummer. CERT-EU empfiehlt das Abschalten, wenn kein Patch möglich ist.

Zuerst sollten alle PHP-Laufzeiten erfasst werden. Dazu gehören PHP-FPM, Apache mod_php, CGI, Container, CI-Runner, cPanel, Plesk, XAMPP und Geräte mit eingebettetem PHP. Internetseitig erreichbare Systeme sowie alle Installationen mit PHP 8.1 oder älter gehören auf die Notfallliste. Das Upgrade sollte vorbereitet und die Zuständigkeit für einen Neustart geklärt werden. Cloudflare-Kunden sollten verwaltete Regeln auf Blockieren statt nur Protokollieren stellen und den direkten Zugriff auf den Origin unterbinden.

Nach der Veröffentlichung müssen unterstützte Zweige sofort über php.net oder das jeweilige Distributions-Advice aktualisiert werden. PHP-FPM, Apache, Laravel Octane und Queue-Worker brauchen einen Neustart, weil langlebige Prozesse den alten Interpreter im Speicher behalten. Die Prüfung muss am ausliefernden Prozess erfolgen, nicht nur über `php -v` in der Shell. Kunden von Managed-Hosting sollten ihren Anbieter nach dem Termin für das korrigierte PHP-Paket fragen.

Zur Nachkontrolle gehören neue oder veränderte PHP-Dateien in Webroots und Upload-Verzeichnissen, neue CMS-Administratoren, unerwartete ausgehende Verbindungen und abstürzende PHP-Worker. Fehlgeschlagene Exploit-Versuche können laut Forschern Worker zum Absturz bringen. Eine Häufung von 5xx-Fehlern bei POST-Anfragen verdient deshalb eine Untersuchung. Ein exponierter Server mit einem ausgelaufenen PHP-Zweig sollte bis zur Prüfung als kompromittiert gelten. Danach sind dort verwendete Zugangsdaten, API-Schlüssel und Cloud-Rollen zu ersetzen.