Am 20./21. Oktober 2026 sind zwei kritische Sicherheitslücken im PHP-Interpreter bekannt geworden, die unter dem Namen PHP2Shell (CVE-2026-109618 und CVE-2026-109619) zusammengefasst werden. Beide haben einen CVSS-Score von 9,2 (kritisch) und ermöglichen unter bestimmten Bedingungen eine unauthentifizierte Remote Code Execution (RCE) – also die Ausführung von Schadcode auf dem Server ohne vorherigen Login.
Die Lücken liegen nicht in WordPress, Drupal, Laravel oder einem Plugin, sondern direkt im PHP-Kern. Selbst eine vollständig aktuelle Anwendung auf einer verwundbaren PHP-Version ist betroffen. PHP treibt einen Großteil des Webs an (WordPress allein macht einen erheblichen Anteil aus). Die Patches sind seit dem 21. Oktober verfügbar.
Was genau ist das Problem?
Beide Schwachstellen betreffen die Speicherverwaltung und das Aufräumen nach fehlgeschlagenen oder abgebrochenen Requests:
- CVE-2026-109618 (RCE via OOM-Korruption): Wenn PHP während der Verarbeitung einer Anfrage (z. B. durch einen speziell präparierten Multipart-/Datei-Upload) an das Speicherlimit stößt, kann die anschließende Aufräumroutine mit nur teilweise initialisierten Daten arbeiten. Das kann zu Codeausführung führen. Besonders kritisch bei Apache mit mod_php – hier ist ein Angriff möglich, bevor überhaupt Anwendungscode läuft.
- CVE-2026-109619 (RCE via veraltetem globalen Zustand): Interne Zustände eines Requests können nach dem Freigeben des Speichers bestehen bleiben. Der nächste Request auf demselben Worker kann diese Daten nutzen (Use-after-Free). Ein bestätigter Weg führt über die standardmäßig aktive Session-Upload-Progress-Funktion.
Die Lücken betreffen PHP-Versionen ab etwa 5.4 (teilweise seit über 20 Jahren). Offizielle Binär-Updates gibt es nur für die noch unterstützten Zweige:
| PHP-Zweig | Fix ab Version |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
Für PHP 7.4, 8.0 und 8.1 gibt es nur minimale Quellcode-Backports (die Versionen sind End-of-Life). PHP 8.2 läuft Ende 2026 aus dem Support.
Angriffe benötigen in vielen Fällen keine Anmeldung und können vor dem eigentlichen Anwendungscode ansetzen. Zusätzlich ist eine Speicherauslese möglich (Passwörter, Tokens, API-Keys oder andere sensible Daten aus dem PHP-Prozess). Exploitation-Versuche wurden bereits gemeldet; die Situation entwickelt sich dynamisch.
Wer ist betroffen?
- Alle Server und Hosting-Umgebungen, die PHP für Web-Requests bereitstellen (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed usw.). Höchstes Risiko bei mod_php.
- WordPress-, Drupal-, Joomla-, Laravel-, Magento- und ähnliche Seiten – unabhängig vom Update-Status der Anwendung.
- Shared-Hosting-Kunden, eigene Server, Docker-Container, Cloud-Instanzen und eingebettete PHP-Runtimes.
Reine CLI-Nutzung von PHP (ohne Web-SAPI) ist in der Regel nicht betroffen. Windows-PHP-Installationen können ebenfalls angreifbar sein.
Was Nutzer und Betreiber jetzt tun können
1. Sofort aktualisieren (die einzige vollständige Lösung)
Prüfen Sie die tatsächlich laufende PHP-Version (php -v oder phpinfo()) und aktualisieren Sie auf eine der gepatchten Versionen. Danach alle PHP-Worker/Prozesse neu starten und die Version erneut verifizieren (nicht nur die Paketversion auf der Festplatte).
- Linux-Distributionen (Ubuntu, Debian, Fedora, AlmaLinux usw.) haben in der Regel bereits gepatchte Pakete ausgerollt – System-Updates einspielen.
- Bei Shared Hosting: Beim Anbieter nachfragen oder im Control Panel (Plesk, cPanel, ISPConfig etc.) die PHP-Version hochsetzen. Viele Hoster haben bereits reagiert.
- Docker/Container: Images aktualisieren und neu deployen.
- Ältere Versionen (≤ 8.1): Auf mindestens PHP 8.3 oder höher migrieren. Das ist langfristig ohnehin nötig.
2. Temporäre Risikoreduktion (nur Überbrückung)
Diese Maßnahmen sind unvollständig und ersetzen kein Update:
session.upload_progress.enabled = 0setzen und Worker neu starten.- Bei PHP 8.5 zusätzlich
fatal_error_backtraces = 0. - Speicherlimits und Upload-Größen sinnvoll begrenzen; Request-Größen am Webserver oder Reverse Proxy (Nginx/Apache) limitieren.
- Wo möglich:
pm.max_requests = 1(bei FPM), um denselben Worker nicht mehrfach zu nutzen.
3. Nach dem Patch bzw. bei Verdacht
- Zugangsdaten, API-Keys, Session-Secrets und Zertifikate rotieren, falls der Server vor dem Patch öffentlich erreichbar war (Speicherauslese möglich).
- Logs auf ungewöhnliche Multipart-Uploads, auffällige Requests oder Worker-Crashes prüfen.
- Anwendungen und Plugins trotzdem aktuell halten – das schützt aber nicht vor diesen Kern-Lücken.
4. Für typische Zielgruppen
- Website-Betreiber mit Shared Hosting: Kontakt zum Hoster aufnehmen, PHP-Version im Panel prüfen/hochsetzen, WordPress-Core und Plugins aktualisieren.
- Eigene Server / VPS: Paketmanager nutzen oder PHP neu bauen, Worker neu starten, Firewall und Monitoring verstärken.
- Agenturen und Entwickler: Alle Kunden-Installationen inventarisieren und priorisiert patchen. Docker-Images und CI/CD-Pipelines anpassen.
- Endnutzer ohne eigenen Server: Beim Hoster oder der Agentur nachfragen, ob gepatcht wurde. Bei Unsicherheit vorübergehend sensible Funktionen (Login, Uploads) beobachten.
Fazit und Empfehlung
PHP2Shell ist eine der schwerwiegendsten PHP-Kern-Schwachstellen der letzten Jahre, weil sie so weit verbreitet ist und keinen Login erfordert. Die Patches liegen seit dem 21. Oktober vor – die wichtigste Maßnahme ist das sofortige Update auf 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 (oder die entsprechenden Distributionspakete) plus Worker-Neustart.
Wer ältere PHP-Versionen nutzt, sollte die Migration jetzt angehen. Nationale und internationale CERTs (u. a. CERT-EU) empfehlen höchste Priorität. Überprüfen Sie Ihre Umgebung heute, nicht nächste Woche.
Offizielle Informationen: PHP-Security-Release auf php.net, GitHub Security Advisories (GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp) sowie die Mitteilung der PHP Foundation.
