Was ist die PHP-Sicherheitslücke PHP2Shell?

Was ist PHP2Shell?

PHP2Shell ist der inoffizielle Name für zwei kritische Schwachstellen im PHP-Interpreter mit den Kennungen CVE-2026-109618 und CVE-2026-109619. Das PHP-Sicherheitsteam bewertet beide mit 9,2 von 10 Punkten (CVSS v4.0). Der Name stammt von einem Angriffswerkzeug, dessen Screenshot zusammen mit ersten Informationen geleakt wurde.
Am 20. Oktober kündigte das PHP-Team ein außerplanmäßiges Sicherheitsupdate an; am selben Tag gelangten erste Details vorzeitig an die Öffentlichkeit. Mit dem Release heute Nachmittag werden die technischen Einzelheiten offiziell veröffentlicht.
Die Lücke steckt in PHP als Laufzeitumgebung, nicht in einem einzelnen CMS oder Plugin. Damit sind potenziell alle PHP-basierten Websites betroffen, etwa WordPress, Joomla, TYPO3, Shopware, Magento oder Eigenentwicklungen.

Wie funktioniert die Lücke grundsätzlich?

Nach bisherigen, nicht offiziell bestätigten Berichten handelt es sich um Speicherfehler, die PHP beim Verarbeiten von Formular- und Datei-Uploads auslöst. Ein Angreifer schickt dazu eine speziell präparierte Upload-Anfrage an die Website.

Drei Eigenschaften machen die Lücke besonders gefährlich:
• Vor der Anwendung: Der Fehler tritt auf, während PHP die Anfrage entgegennimmt, also bevor Ihr CMS oder Ihre Anwendung startet. Sicherheits-Plugins, Login-Prüfungen oder Anwendungs-Updates greifen deshalb nicht.
• Ohne Anmeldung: Für einen Angriff sind voraussichtlich keine Zugangsdaten nötig.
• Standardkonfiguration: Die betroffenen Funktionen sind in der PHP-Standardkonfiguration aktiv.

Im Mittelpunkt der Berichte steht die PHP-Funktion für den Upload-Fortschritt (session.upload_progress). Der Entdecker behauptet zudem einen zweiten Angriffsweg über die allgemeine Verarbeitung von Upload-Anfragen (multipart/form-data). Gelingt der Angriff, kann der Angreifer eigenen Code mit den Rechten des PHP-Prozesses ausführen und typischerweise eine Shell auf dem Server öffnen – daher der Name.
Auf weitere technische Einzelheiten verzichten wir hier bewusst. Die offizielle Beschreibung erscheint mit dem PHP-Release.

Bin ich betroffen?

Wahrscheinlich ja, wenn auf Ihrem Server PHP läuft und die Website aus dem Internet erreichbar ist. Das PHP-Team hat die betroffenen Versionen noch nicht genannt. Das geleakte Werkzeug nennt alle Versionen ab PHP 5.4; CERT-EU hält alle Versionen ab PHP 5 für möglicherweise betroffen.
PHP-Version
Status beim PHP-Projekt
Offizielles Update
8.5, 8.4
aktiv unterstützt
ja, erwartet als 8.5.12 / 8.4.27
8.3, 8.2
nur Sicherheitsupdates
ja, erwartet als 8.3.36 / 8.2.35
8.1 und älter (inkl. 7.x, 5.x)
End of Life
nein
Die erwarteten Versionsnummern sind nicht offiziell bestätigt; maßgeblich ist die Ankündigung auf php.net. Viele Linux-Distributionen spielen Korrekturen als eigene Paketversionen ein, ohne dass sich die PHP-Versionsnummer ändert. Prüfen Sie deshalb auch die Sicherheitsmeldungen Ihres Distributors.
Welche Betriebsarten betroffen sind, ist offiziell noch offen. Gehen Sie vorsorglich davon aus, dass PHP-FPM, mod_php, CGI und eingebettete Varianten wie FrankenPHP gleichermaßen betroffen sind.

Wird die Lücke bereits ausgenutzt?

Es gibt erste Hinweise darauf. Laut dem CTO von Cloudflare wurden am Morgen des 21. Oktober erste Angriffe beobachtet; die Sicherheitsfirmen Huntress und watchTowr hatten am 20. Oktober noch keine Ausnutzung festgestellt. Ein angeblicher Proof-of-Concept kursiert öffentlich, seine Wirksamkeit ist umstritten.
Sicherheitsforscher, unter anderem von Sansec, rechnen mit automatisierten Massenscans unmittelbar nach dem Release. Gehen Sie davon aus, dass ungepatchte, öffentlich erreichbare PHP-Systeme ab heute Nachmittag aktiv angegriffen werden.

Was ist die wichtigste Maßnahme?

Das PHP-Update so schnell wie möglich einspielen. Nach Aussage des PHP-Teams ist das die einzige wirksame Abhilfe; alle anderen Maßnahmen verringern nur das Risiko.

Dabei sollten Sie beachten:
• Updates über die Paketquellen Ihrer Distribution oder Ihres Panels (z. B. Plesk, cPanel, DirectAdmin) beziehen. Diese folgen oft mit etwas Verzögerung auf das offizielle Release.
• Alle installierten PHP-Versionen aktualisieren, nicht nur die Standardversion.
• Nach dem Update alle PHP-Prozesse neu starten (z. B. PHP-FPM, Apache mit mod_php, langlaufende Worker). Laufende Prozesse behalten sonst den alten Code im Speicher.
• Programme mit fest eingebautem PHP (z. B. FrankenPHP) werden nicht über das Paketsystem aktualisiert; hier ist ein neues Release des jeweiligen Projekts nötig.
• Anschließend kontrollieren, ob die neue Version tatsächlich aktiv ist.

Welche Übergangsmaßnahmen gibt es bis zum Update?

Bis das Update eingespielt ist, können folgende Maßnahmen das Risiko senken. Keine davon ist gegen den echten Exploit bestätigt, und keine ersetzt das Update.
Maßnahme
Wirkung laut bisherigen Berichten
Einschränkung
Upload-Fortschritt abschalten (session.upload_progress.enabled)
Schaltet den Codepfad ab, auf den sich der geleakte Angriff stützen soll
Deckt den behaupteten zweiten Angriffsweg vermutlich nicht ab
Upload-Anfragen (multipart) am Webserver oder Proxy blockieren
Anfrage erreicht PHP gar nicht erst; könnte beide Wege abdecken
Datei-Uploads und manche Formulare funktionieren nicht mehr; freigegebene Ausnahmen bleiben angreifbar
Web Application Firewall (z. B. Regeln von Cloudflare)
Filtert bekannte Angriffsmuster
Wirkt nur, wenn der Server nicht direkt, an der WAF vorbei, erreichbar ist
Programmausführung durch PHP unterbinden (SELinux/AppArmor)
Verhindert den typischen letzten Schritt zur Shell
Verhindert nicht den Speicherfehler selbst (siehe nächste Frage)

Hinweise zur Umsetzung:
• Setzen Sie die PHP-Einstellung so, dass sie nicht durch eigene Konfigurationen im Webspace (etwa .user.ini oder .htaccess) wieder überschrieben werden kann. Prüfen Sie den tatsächlich wirksamen Wert für jede PHP-Version und Betriebsart.
• Die Upload-Fortschrittsfunktion zeigt nur einen Fortschrittsbalken bei Uploads an und wird von gängigen CMS kaum genutzt. Uploads selbst funktionieren weiter.
• Konkrete Konfigurationsbeispiele finden Sie in den Quellen unter „Wo finde ich weitere Informationen?“. Testen Sie Änderungen vor dem produktiven Einsatz.
Für Systeme, die sich weder aktualisieren noch absichern lassen, bleibt als letzte Option die vorübergehende Abschaltung.

Kann ich SELinux oder AppArmor nutzen?

Ja, und wir empfehlen es ausdrücklich als zusätzliche Schutzschicht. SELinux (u. a. RHEL, AlmaLinux, Rocky Linux, Fedora) und AppArmor (u. a. Ubuntu, Debian, SUSE) sind Sicherheitsmodule des Linux-Kernels. Sie legen fest, was ein Prozess darf – unabhängig davon, was im Prozess selbst passiert.
Warum das hier hilft: Ein Angriff über PHP2Shell endet nach bisherigen Berichten typischerweise damit, dass der PHP-Prozess eine Shell oder ein anderes Programm startet. Darf der PHP-Prozess per Richtlinie keine fremden Programme ausführen, scheitert dieser letzte Schritt. Der Sicherheitsforscher Kevin Beaumont hat diesen Ansatz öffentlich als wirksame Mitigation gegen diese CVEs empfohlen.
Was es nicht leistet: Der Speicherfehler selbst bleibt bestehen. Code, der direkt im PHP-Prozess läuft, kann weiterhin alles lesen, was PHP lesen darf, zum Beispiel Dateien der Website oder Datenbank-Zugangsdaten. SELinux und AppArmor begrenzen also den Schaden, ersetzen aber nicht das Update. Unabhängig gegen den echten Exploit getestet ist der Ansatz bisher nicht.

Grundzüge der Umsetzung:
• Prüfen, ob SELinux bzw. AppArmor aktiv ist und im erzwingenden Modus läuft, nicht nur protokollierend.
• Für den PHP-Prozess (PHP-FPM bzw. den Webserver bei mod_php) eine Richtlinie oder ein Profil verwenden, das das Starten von Shells und anderen Programmen verbietet.
• Vorher klären, ob Ihre Anwendung legitim externe Programme aufruft (z. B. Bildverarbeitung, Mailversand über sendmail). Diese Aufrufe müssen gezielt erlaubt oder umgestellt werden.
• Neue Regeln zunächst im Lern- bzw. Protokollmodus testen und die Logs auswerten, bevor Sie sie scharf schalten.

Eine fertige Anleitung geben wir hier bewusst nicht, weil Richtlinien stark von Distribution, PHP-Betriebsart und Anwendung abhängen. Ausgangspunkte für Ihre eigene Recherche sind die SELinux- bzw. AppArmor-Dokumentation Ihrer Distribution sowie die Suchbegriffe am Ende dieser FAQ.
Ergänzend lässt sich in PHP die Liste deaktivierter Funktionen (disable_functions) um Funktionen zur Programmausführung erweitern. Bei Speicherfehlern bietet das aber keinen verlässlichen Schutz und ersetzt die Absicherung auf Betriebssystemebene nicht.

Was hilft voraussichtlich nicht?

Nach bisherigen Berichten reichen folgende Maßnahmen allein nicht aus:
• Updates von CMS, Plugins oder Themes: Die Lücke greift, bevor die Anwendung startet. Aktuelle Anwendungen erschweren es Angreifern aber, sich nach einem Einbruch festzusetzen.
• Maßnahmen im Anwendungscode: Sicherheits-Plugins, Login-Schutz oder Wartungsmodus laufen erst, nachdem PHP die Anfrage verarbeitet hat.
• Datei-Uploads in PHP abschalten (file_uploads = Off): PHP verarbeitet die Anfrage laut Berichten trotzdem.
• Kleinere Upload- oder POST-Größenlimits: Eine sichere Grenze ist nicht bekannt.
• WAF oder CDN bei direkt erreichbarem Server: Angreifer können den Schutz umgehen, indem sie den Server direkt ansprechen.

Was tun bei alten PHP-Versionen (8.1 und älter)?

Für PHP 8.1 und ältere Versionen wird das PHP-Projekt kein Update veröffentlichen. Ob diese Versionen betroffen sind, ist offiziell noch offen; Sie sollten aber davon ausgehen.

Mögliche Wege:
• Prüfen, ob Ihr Distributor oder ein Anbieter erweiterter Pflege für ältere PHP-Versionen Korrekturen zurückportiert. Solche Pakete erscheinen in der Regel erst nach dem offiziellen Release.
• Die Übergangsmaßnahmen und SELinux/AppArmor dauerhaft aktiv halten, bis eine Lösung vorliegt.
• Die Migration auf eine unterstützte PHP-Version einplanen. Beachten Sie: PHP 8.2 erhält laut BSI nur noch bis Jahresende Sicherheitsupdates.
• Systeme, die sich weder aktualisieren noch absichern lassen, vorübergehend vom Netz nehmen.

Woran erkenne ich eine mögliche Kompromittierung?

Da bereits vor dem Release Angriffe gemeldet wurden, sollten Sie Ihre Systeme auch nach dem Update prüfen.

Mögliche Hinweise:
• PHP- oder Webserver-Prozesse (php-fpm, httpd, apache2), die unerwartet Shells oder andere Programme starten.
• Auffällige Upload-Anfragen in den Webserver-Logs, besonders an Pfade, die normalerweise keine Uploads erhalten.
• Häufige Abstürze oder Neustarts von PHP-Prozessen; sie können auf Angriffsversuche gegen Speicherfehler hindeuten.
• Unbekannte Dateien im Webspace, neue Administratorkonten im CMS, unerwartete Weiterleitungen oder ausgehende Verbindungen.
• Bei aktivem SELinux oder AppArmor: Einträge im Audit- bzw. Kernel-Log über verweigerte Programmausführungen durch PHP.
Bei konkretem Verdacht sollten Sie das System isolieren, Spuren sichern und nach der Bereinigung alle Zugangsdaten ändern, auf die PHP Zugriff hatte (Datenbank, API-Schlüssel, Admin-Konten).

Wo finde ich weitere Informationen?

Verbindliche Angaben kommen vom PHP-Projekt und von Ihrem Distributor. Konkrete Konfigurationsbeispiele entnehmen Sie bitte den folgenden Quellen und prüfen sie vor dem Einsatz für Ihre Umgebung.

Offizielle Stellen:
• PHP-Projekt: Ankündigungen und Changelogs auf php.net, Support-Zeiträume unter Supported Versions
• CERT-EU: Security Advisory 2026-018
• BSI: aktuelle Warnmeldungen zu CVE-2026-109618 und CVE-2026-109619
• Sicherheitsmeldungen Ihrer Linux-Distribution bzw. Ihres Hosting-Panels

Hintergrund und Mitigationen:
• Mattias Geniar: PHP CVE-2026-109618 and CVE-2026-109619 – early mitigation steps (Stand der Fakten, umstrittene Punkte, Konfigurationsbeispiele)
• Tenable: PHP2Shell FAQ
• The Hacker News: PHP2Shell
• SecurityWeek: PHP2Shell
• LocateRisk: Übersicht auf Deutsch

Suchbegriffe für die eigene Recherche:
• „CVE-2026-109618“ bzw. „CVE-2026-109619“ zusammen mit dem Namen Ihrer Distribution oder Ihres Panels
• „session.upload_progress.enabled php-fpm pool“
• „AppArmor php-fpm profile deny exec“
• „SELinux httpd php-fpm policy“ bzw. „SELinux httpd booleans“