Kritische Warnung · PHP-Engine

  • CVSS 9,2
  • RCE ohne Authentifizierung
  • Behoben am 21.10.2026

PHP2Shell: zwei kritische Schwachstellen in der PHP-Engine.

CVE-2026-109618 und CVE-2026-109619 ermöglichen die Ausführung von Code aus der Ferne, ohne Authentifizierung, auf jedem Server, der PHP-Seiten ausliefert. So finden Sie in zwei Minuten heraus, ob Sie betroffen sind, und so beheben Sie das Problem.

Meine Projekte prüfen Befehle ansehen

Aktualisiert am 22. Oktober 2026 um 10:30 Uhr · Quellen: php.net, CERT-FR, CISA

Mit einer KI lesen .md-Version

Das Wichtigste in 60 Sekunden

Betroffen ist die Engine, nicht Ihr Code.

Beide Schwachstellen stecken im PHP-Interpreter selbst. Jeder Server, der Webanfragen mit einer ungepatchten Version verarbeitet, ist angreifbar.

Ein CMS-Update reicht nicht.

Aktuelle Versionen von WordPress, Symfony, Laravel oder Ihren Composer-Paketen ändern nichts: Ersetzt werden muss das PHP-Binary auf dem Server.

Nur eine Maßnahme behebt das Problem wirklich.

Auf 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 aktualisieren und danach die PHP-Prozesse neu starten. Workarounds blockieren nur einen Teil der Angriffe.

Was passiert

Zwei Speicherfehler im Kern des Interpreters

Sie werden während der Verarbeitung einer HTTP-Anfrage ausgelöst, noch bevor Ihre Anwendung läuft.

CVE-2026-109618 CVSS 9,2

Speicherbeschädigung bei Speichermangel

Schlägt eine Speicherallokation beim Parsen einer Anfrage fehl, bricht PHP die Verarbeitung ab und hinterlässt halb initialisierte Strukturen. Die Bereinigung am Ende der Anfrage verwendet sie wieder: Ein Angreifer kann sie mit einer präparierten Anfrage übernehmen.

Apache mit mod_php ist die am stärksten gefährdete Konfiguration.

CVE-2026-109619 CVSS 9,2

Freigegebener Speicher, der zwischen zwei Anfragen wiederverwendet wird

Ein PHP-Prozess verarbeitet mehrere Anfragen nacheinander. Nach einem fatalen Fehler zeigt ein interner Zustand noch auf freigegebenen Speicher, den die nächste Anfrage erneut liest. Die Fortschrittsanzeige für Datei-Uploads (session.upload_progress, standardmäßig aktiv) ist der bekannte Angriffsweg.

Betrifft PHP-FPM, mod_php, FrankenPHP und LiteSpeed.

Wer betroffen ist

Ihr PHP-Branch und was zu tun ist

Die Supportdaten jedes Branches stammen aus dem offiziellen Kalender von php.net. Ein Branch nach seinem Supportende erhält keine korrigierten Versionen mehr.

BranchVerwundbarBehoben inOffizieller SupportZu tun
8.5 8.5.0 bis 8.5.11 8.5.12 Aktiv · Sicherheit → 2029 Auf 8.5.12 aktualisieren
8.4 8.4.0 bis 8.4.26 8.4.27 Aktiv · Sicherheit → 2028 Auf 8.4.27 aktualisieren
8.3 8.3.0 bis 8.3.35 8.3.36 Nur Sicherheit → 2027 Auf 8.3.36 aktualisieren
8.2 8.2.0 bis 8.2.34 8.2.35 Endet am 31.12.2026 Heute patchen, vor dem 31.12. migrieren
8.1 und älter Alle keine Beendet seit 31.12.2025 Gepatchtes Paket Ihrer Distribution oder Migration auf 8.3+

PHP 8.2 erreicht in zehn Wochen sein Supportende

Patchen Sie heute auf 8.2.35 und planen Sie dann die Migration auf 8.3 oder 8.4. Nach dem 31. Dezember 2026 bleiben 8.2-Server bei einer neuen Schwachstelle der Engine ohne Patch, wie heute schon 8.1.

In 2 Minuten prüfen

Schauen Sie an zwei Stellen nach: im Repository und auf dem Server

Das Repository sagt, welche PHP-Version das Projekt erwartet. Der Server sagt, welche tatsächlich läuft. Beides zählt.

Im Repository · deklarierte Version 
$ grep -E '"php"' composer.json
  "php": "^8.1"

$ composer show --platform | grep -E "^php "
php   8.1.29   The PHP interpreter
Was das bedeutet 
"php": "^8.1"  → das Projekt akzeptiert 8.1: Branch nach Supportende
"php": "^8.2"  → auf 8.2.35 patchen, vor dem 31.12.2026 migrieren
"php": "^8.3"  → auf 8.3.36 oder neuer patchen
Auf dem Server 
$ php -v
$ ps aux | grep -E 'php-fpm|lsphp'
In WordPress 
Werkzeuge › Website-Zustand › Bericht › Server

Die Befehle für „Auf Ihren Servern“ und „WordPress“ erscheinen, wenn Sie auf Schritt 2 oder 3 klicken.

Was LibWatch für Sie tut

Alle Ihre PHP-Projekte auf einen Schlag geprüft und jede Nacht überwacht.

  • Erkennt die PHP-Version, die jedes Repository und jede WordPress-Website deklariert, und gleicht sie mit Schwachstellen und Supportende ab.
  • Bezieht die Warnungen des CERT-FR zu PHP ein: Eine betroffene exakte PHP-Version (8.2.30, nicht ^8.2) wird spätestens in der folgenden Nacht gemeldet.
  • Prüft jede Nacht alles erneut, auch Projekte, die niemand anfasst, und benachrichtigt das Team per E-Mail, Slack, Zulip oder Webhook.

Die Grenze: LibWatch sieht die im Repository deklarierte Version, nicht unbedingt die auf Ihren Servern installierte. Prüfen Sie zusätzlich php -v in der Produktion.

Meine Projekte prüfen Oder testen Sie eine composer.lock ohne Konto →

Ihr Code bleibt bei Ihnen: LibWatch liest Ihre Abhängigkeitsdateien und speichert nur die Liste Ihrer Pakete und deren Versionen. So funktioniert es →

Beheben

Drei Schritte, und der zweite wird oft vergessen

Nur ein PHP-Update behebt beide Schwachstellen. Bewahren Sie Ihre Zugriffs- und Fehlerprotokolle auf: Ausnutzungsversuche wurden bereits ab dem 17. Oktober beobachtet.

PHP aktualisieren oder Ihre Docker-Images neu bauen

Ein Update des Hosts behebt nicht das PHP, das in einem Container läuft: Bauen Sie das Image auf einer gepatchten Basis neu.

Unter Debian / Ubuntu 
$ sudo apt update && sudo apt install --only-upgrade 'php*'

# Docker: von einem gepatchten Basis-Image neu starten
$ docker build --pull --no-cache -t mon-app:corrigee .

Alle PHP-Prozesse neu starten

Ohne Neustart bleibt die alte, verwundbare Version im Speicher geladen, auch wenn das Paket auf der Festplatte aktuell ist.

Neu starten und prüfen 
$ sudo systemctl restart php8.3-fpm
$ sudo systemctl restart apache2

# die Startzeit muss nach dem Update liegen
$ ps -eo pid,lstart,cmd | grep -E 'php-fpm|apache2'

Die ausgelieferte Version prüfen

Prüfen Sie die Version, die eine echte Webanfrage sieht, nicht nur die der Kommandozeile: Die beiden können sich unterscheiden.

Vorübergehende Workarounds

Wenn Sie nicht innerhalb einer Stunde patchen können

Blockiert

Die Upload-Fortschrittsanzeige deaktivieren

  • — Die bekannten Angriffswege von CVE-2026-109619.
  • — Datei-Uploads funktionieren weiterhin normal.
  • — Wirkt erst nach einem Neustart der PHP-Prozesse.
php.ini 
session.upload_progress.enabled = Off

Blockiert nicht

Was offen bleibt

  • — CVE-2026-109618, die Speicherbeschädigung bei Speichermangel.
  • — Andere mögliche Wege zur zweiten Schwachstelle.
  • — WAF-Regeln (Cloudflare, AWS, Azure…) verringern das Risiko, ersetzen aber nicht das Update.

Nur ein PHP-Update behebt das Problem

Die PHP-Entwickler, das CERT-FR und die CISA sagen es übereinstimmend: Ein Workaround verschafft Zeit, mehr nicht.

Chronologie

Fünf Tage, vom ersten Angriff bis zu dieser Seite

17.10.2026

Erster Ausnutzungsversuch

Beobachtet von Amazon Threat Intelligence, vier Tage vor dem Patch.

20.10.2026

Leak und vorzeitige Ankündigung

Ein inzwischen gelöschter Beitrag kündigte einen CVSS-Wert von 10 an, der später dementiert wurde: Der offizielle Wert ist 9,2.

21.10.2026

Patches und Warnungen

PHP veröffentlicht 8.5.12, 8.4.27, 8.3.36 und 8.2.35. CERT-FR (ALE-014) und CISA geben Warnungen heraus. Cloudflare rollt WAF-Regeln aus.

22.10.2026

Diese Seite

Wird bei jeder neuen Entwicklung aktualisiert: Aufnahme in den KEV-Katalog, EPSS-Wert, Pakete der Distributionen.

Häufige Fragen

Was man uns seit dem 21. Oktober fragt

Eine andere Frage? Schreiben Sie uns →
Reicht ein Update von WordPress, Symfony oder Laravel?
Nein. Die Schwachstelle steckt in der PHP-Engine des Servers, nicht in Ihrem CMS oder Ihren Composer-Paketen. Solange PHP nicht auf 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 ist und seine Prozesse nicht neu gestartet wurden, bleibt die Website angreifbar.
Ich nutze Shared Hosting oder Managed WordPress: Was soll ich tun?
PHP wird von Ihrem Hoster aktualisiert. Prüfen Sie die ausgelieferte Version unter Werkzeuge › Website-Zustand › Bericht › Server: Ist sie älter als 8.2.35, 8.3.36, 8.4.27 oder 8.5.12, bitten Sie Ihren Hoster um das Update, oder wählen Sie in Ihrem Kundenbereich eine gepatchte Version, sofern das möglich ist.
Warum ein Wert von 9,2 und nicht 10, wie zuerst angekündigt?
Am 20.10.2026 kündigte ein inzwischen gelöschter Beitrag einen CVSS-Wert von 10 an. Das wurde später dementiert: Der offizielle Wert ist 9,2 (CVSS v4.0), für jede der beiden Schwachstellen.
Wie erkenne ich, ob mein Server vor dem Update angegriffen wurde?
Bewahren Sie Ihre Zugriffs- und Fehlerprotokolle auf: Ausnutzungsversuche wurden bereits ab dem 17. Oktober beobachtet, vier Tage vor dem Patch. Das Update schließt die Schwachstellen, macht aber einen früheren Einbruch nicht ungeschehen: Lassen Sie diese Protokolle im Zweifel analysieren.
Braucht LibWatch Zugriff auf meinen Code, um die Schwachstelle zu erkennen?
Nein. LibWatch liest Ihre Abhängigkeitsdateien und speichert nur die Liste Ihrer Pakete und deren Versionen. Die Grenze: LibWatch sieht die im Repository deklarierte Version, nicht unbedingt die auf Ihren Servern installierte. Prüfen Sie zusätzlich php -v in der Produktion.

Quellen

Geprüft am 22.10.2026. Wir aktualisieren diese Seite, sobald sich eine Quelle ändert.