PHP2Shell: Patch-Plan für zwei kritische PHP-Sicherheitslücken

Wenn Ihre Website, Ihr Onlineshop oder Ihre Webanwendung auf PHP läuft, steht heute ein Update an, und es ist kein gewöhnliches. Am 21. Oktober 2026 hat das PHP-Projekt Fixes für zwei kritische Sicherheitslücken veröffentlicht, über die ein Angreifer ohne Anmeldung Code auf Ihrem Server ausführen kann. Forscher nennen sie PHP2Shell. Fast jede PHP-Version der letzten zehn Jahre ist betroffen, und Angreifer haben schon nach den Lücken gesucht, bevor der Fix überhaupt öffentlich war.

Dieser Beitrag erklärt, was PHP behoben hat, wie Sie jede Stelle prüfen und patchen, an der PHP läuft, was Sie tun können, wenn Sie heute nicht aktualisieren können, und was dieser Vorfall darüber sagt, wie schnell Patches inzwischen ankommen müssen. Die Fakten unten entsprechen dem Stand vom 22. Oktober 2026. Die Lage entwickelt sich schnell, prüfen Sie also die offizielle Sicherheitsmeldung auf Neuigkeiten.

Was hat PHP behoben?

Die PHP-Sicherheitsmeldung betrifft zwei Schwachstellen, beide mit 9,2 von 10 bewertet (CVSS v4.0) und beide als Codeausführung aus der Ferne ohne Anmeldung beschrieben.

Schwachstelle	Was schiefgeht, in den Worten von PHP	Bestätigte Auswirkung
CVE-2026-109618, “RCE via OOM corruption"	"out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.” Ein Speichermangel unterbricht PHP also, während interne Anfragedaten erst teilweise eingerichtet sind, und die Aufräumroutine behandelt die ungültigen Daten danach als gültig.	Codeausführung aus der Ferne mit dem PHP-Konto des Webservers
CVE-2026-109619, “RCE via stale global state"	"request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.” Interner Zustand einer Anfrage überlebt also, obwohl sein Speicher schon freigegeben ist, und eine spätere Anfrage im selben Worker nutzt ihn, bevor er zurückgesetzt wird.	Auslesen von Speicher und Codeausführung aus der Ferne

Die korrigierten Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Laut PHP betrifft das Risiko “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed”, also alle PHP-Installationen, die Webanfragen bedienen. Am höchsten ist es bei Apache mit mod_php, wo “an unauthenticated request can trigger the attack before any application code runs”, also eine Anfrage ohne Anmeldung den Angriff auslösen kann, bevor überhaupt Anwendungscode läuft.

Dieser letzte Punkt ist für Unternehmen wichtig. Es ist eine Lücke in der PHP-Engine, nicht in Ihrem Code. Auch eine saubere, gut gepflegte WordPress-, Laravel-, Drupal- oder Magento-Website ist betroffen, wenn das PHP darunter nicht gepatcht ist.

Wie ist es abgelaufen?

Wann (2026)	Was passiert ist
August bis September	Forscher von Calif, OpenAI und Wiz fanden die Lücken. Laut The Register gaben alle drei an, KI-Modelle genutzt zu haben.
17. Oktober	Laut SecurityWeek sah Amazon den ersten Ausnutzungsversuch gegen einen Honeypot, als die Lücken noch geheim waren.
20. Oktober	CVE-Nummern kursierten im Netz. PHP veröffentlichte eine Vorankündigung und zog den Release um einen Tag vor.
21. Oktober, 07:41 UTC	Chainguard veröffentlichte fertige Images mit dem Fix, mehr als sechs Stunden vor dem offiziellen Release. PHP sagt, damit sei das Embargo gebrochen worden. Chainguard sagt, es habe gehandelt, weil bereits angegriffen wurde.
21. Oktober, 14:00 UTC	PHP veröffentlichte die Fixes. Die US-Behörde CISA gab am selben Tag eine Warnung heraus.

Die PHP Foundation hat offen erklärt, warum der Fix gedauert hat. Erste Anzeichen des Speicherproblems wurden bei einem externen Audit 2024 gefunden, ein funktionierender Angriff damals aber nicht. Die anschließende Verzögerung nennt die Foundation “a structural failure, caused by both the security team’s decision process and its lack of resources”, also ein strukturelles Versagen, verursacht durch den Entscheidungsprozess des Sicherheitsteams und fehlende Ressourcen. Sie hat seitdem Personal und Werkzeuge ergänzt und die Entscheidungswege des Sicherheitsteams geändert.

Wird die Lücke ausgenutzt? Versuche gibt es, ja. Bis zum 22. Oktober berichtete SecurityWeek, dass Amazon PHP2Shell als “broadly exploited in the wild” einstuft, also als breit ausgenutzt, und der CEO von Cloudflare meldete Millionen von Versuchen in seinem Netzwerk. Gleichzeitig sagte watchTowr, keiner der kursierenden Proof-of-Concept-Exploits habe auf seinen Sensoren Code ausgeführt, und die CISA erklärte in ihrer Warnung, zum Zeitpunkt der Veröffentlichung keine Ausnutzung beobachtet zu haben. Behandeln Sie die Lücke als aktiv angegriffen und patchen Sie entsprechend.

Bin ich betroffen?

Gehen Sie davon aus, bis Sie es geprüft haben. Laut SecurityWeek zählte Censys am 21. Oktober rund 2,58 Millionen PHP-Hosts mit Internetzugang, von denen etwa 1,57 Millionen noch nicht gepatcht waren.

Listen Sie zuerst jede Stelle auf, an der PHP läuft, nicht nur Ihre Hauptwebsite. Die CISA betont dasselbe: PHP “is often a component of other software”, steckt also oft in anderer Software, sodass Sie es womöglich nutzen, ohne es zu wissen.

• Eigene Server und virtuelle Maschinen, auf denen PHP aus Ihrer Linux-Distribution oder einem Drittanbieter-Repository stammt.
• Container, in denen PHP aus dem Basis-Image kommt, mit dem Ihr Dockerfile beginnt.
• Managed Hosting und Plattformen, bei denen Ihr Anbieter die PHP-Version bestimmt.
• Software mit eingebautem PHP, etwa Admin-Oberflächen, Intranet-Werkzeuge und Appliances.
• Alte Systeme ohne Verantwortlichen, etwa eine vergessene Microsite oder ein Staging-Server, der noch online ist.

Die Patch-Schritte, bei denen Fehler passieren

1. Ein Update der Anwendung aktualisiert nicht PHP. Ein Update von WordPress, Laravel oder per Composer ändert Ihren Code, nicht die PHP-Engine. Der Fix muss aus dem Serverpaket, dem Container-Image oder von Ihrem Hosting-Anbieter kommen.

2. Die Versionsnummer kann täuschen. Linux-Distributionen spielen Fixes in ältere Versionsstände zurück. Unter Ubuntu 24.04 zum Beispiel kam der Fix im Paket php8.3 mit der Version 8.3.6-0ubuntu0.24.04.13, das weiterhin PHP 8.3.6 meldet. Unter Debian 12 ist es php8.2 in der Version 8.2.35-1~deb12u1. Suchen Sie im Changelog des Pakets nach der CVE-Nummer, statt der Versionsangabe zu vertrauen. Sansec schlägt Befehle wie diese vor:

# Debian and Ubuntu (replace 8.3 with your PHP version)
zgrep CVE-2026-109618 /usr/share/doc/php8.3-common/changelog.Debian.gz

# RHEL, AlmaLinux and Rocky Linux
rpm -q --changelog php-common | grep CVE-2026-109618

Ein Treffer bedeutet, dass das korrigierte Paket installiert ist.

3. Installiert heißt nicht ausgeführt. Ein laufender PHP-FPM-Pool oder Apache-Prozess behält den alten Code im Speicher, bis er neu startet. Starten Sie nach dem Update jeden PHP-Prozess neu und prüfen Sie dann die Version, die tatsächlich Anfragen bedient, nicht nur das Kommandozeilen-php:

sudo systemctl restart php8.3-fpm   # Debian/Ubuntu PHP-FPM service name
sudo systemctl restart apache2      # Apache with mod_php (httpd on RHEL-family systems)

php -v          # the command-line PHP
php-fpm8.3 -v   # the PHP-FPM binary that serves web requests

4. Container brauchen einen Neubau und ein neues Deployment. Ein Dockerfile, das von einem PHP-Basis-Image ausgeht, bekommt den Fix erst, wenn Sie es aus einem aktualisierten Basis-Image neu bauen und das neue Image ausrollen. Prüfen Sie den laufenden Container, nicht das Dockerfile:

docker exec <container> php -v

5. PHP 8.1 und älter bekommen keinen offiziellen Release. Das PHP-Projekt aktualisiert diese Versionen nicht mehr. Es hat minimale Quellcode-Patches für 7.4, 8.0 und 8.1 veröffentlicht, für alle, die PHP selbst kompilieren, und manche Distributionen liefern eigene Fixes. Ubuntu 22.04 zum Beispiel bietet ein korrigiertes php8.1-Paket. Die CISA geht weiter: Organisationen, die nicht aktualisieren können oder noch PHP 8.1 oder älter nutzen, sollten PHP-basierte Systeme vom Netz nehmen, bis sie gepatcht sind. PHP 8.2 selbst erreicht am 31. Dezember 2026 das Ende des Supports, planen Sie dieses Upgrade also jetzt mit.

6. Der Fix ändert das Verhalten von Speichergrenzen. Laut der PHP-Meldung ersetzt der Patch die alte Behandlung von Speichermangel durch einen geordneten Stopp am nächsten sicheren Punkt, dazu einen sofortigen harten Stopp, wenn der Speicherverbrauch eine zweite, höhere Schwelle erreicht. Eine Anfrage, die den harten Stopp auslöst, beendet den Prozess, ohne Shutdown-Handler auszuführen. Prüfen Sie, ob memory_limit und post_max_size noch zu dem passen, was Ihre Anwendung wirklich braucht.

Wenn Sie heute nicht aktualisieren können

PHP ist eindeutig: “only an update is a complete solution”, nur ein Update ist eine vollständige Lösung. Die Meldung nennt Maßnahmen, die die bekannten Angriffswege eingrenzen, sagt aber, dass sie “do not make an installation safe”, eine Installation also nicht sicher machen. Kurz gefasst:

; Apply in php.ini, the FPM pool or the server configuration, then restart every worker.
; Do not rely on ini_set() or .user.ini for these.
memory_limit = -1
post_max_size = 8M        ; 32M if your application needs file uploads
upload_max_filesize = 2M  ; keep below post_max_size
session.upload_progress.enabled = 0

• Setzen Sie unter PHP 8.5 zusätzlich fatal_error_backtraces=0 und starten Sie jeden Worker neu.
• Setzen Sie Anfragegrenzen am Webserver oder Proxy durch, darunter Größe des Inhalts, Anzahl der Felder und Anzahl der Multipart-Teile. Laut Sansec nutzen alle bekannten Angriffe Anfragen vom Typ multipart/form-data. Wenn Ihre Anwendung keine Multipart-Formulare annimmt, blockieren Sie sie vor PHP. Wenn doch, testen Sie Uploads und Checkout nach jeder Änderung.
• Nutzen Sie RLIMIT_AS oder RLIMIT_DATA nicht als Speichergrenze. PHP warnt, dass sie den verwundbaren Pfad auslösen können.
• Eine Web Application Firewall hilft, aber nur teilweise. Laut CISA “may provide some protection”, sie kann also etwas Schutz bieten, und Angreifer haben ihre Anfragen verändert, um Firewall-Regeln zu umgehen.
• Fehler zu verstecken hilft nicht. Die PHP-Meldung weist darauf hin, dass error_reporting, display_errors und @ nicht davor schützen.

Aktualisieren Sie danach so bald wie möglich. Das sind Notlösungen, keine Fixes.

Anzeichen, dass ein Server schon kompromittiert ist

Der Patch schließt die Tür, verrät aber nicht, ob vorher jemand eingedrungen ist. Prüfen Sie die Tage vor Ihrem Patch, ab dem 17. Oktober. Die Forscher und Behörden, die PHP2Shell verfolgen, nennen die ersten vier Signale unten. Das letzte ist das übliche Zeichen jeder Kompromittierung einer Website:

• PHP-Worker-Prozesse, die Shells starten oder Werkzeuge herunterladen, was die CISA als wichtigen Prüfpunkt nennt.
• Ungewöhnliche Anfragen vom Typ multipart/form-data an PHP-Endpunkte, besonders gefolgt von Fehlern wegen Speichergrenzen.
• Wiederholte HTTP-500-Antworten und unerklärliche Neustarts von PHP-Workern.
• Übergroße PHPSESSID-Cookies in Antworten. Sansec warnt, dass das Auslesen von Speicher Daten über dieses Cookie preisgeben kann.
• Neue oder geänderte PHP-Dateien in Upload-, Cache- oder Webroot-Ordnern, das klassische Zeichen einer Web-Shell.

Wenn ein Server mit Internetzugang eine verwundbare Version ausgeführt hat, ist es ratsam, Geheimnisse, die der PHP-Prozess lesen konnte, als offengelegt zu behandeln: Datenbankpasswörter, API-Schlüssel und Tokens in Umgebungsdateien. Tauschen Sie sie nach dem Patch aus, beginnend mit den sensibelsten.

Warum das Zeitfenster für Patches geschrumpft ist

Die wichtigste Lehre aus PHP2Shell betrifft nicht nur PHP. Diese Fehler steckten seit mehr als zehn Jahren im Code. KI-Modelle halfen drei Forschungsteams, sie zu finden, und Chainguard sagt, sein eigenes Team habe dieselben Fehler in einer Nacht mit einem KI-Werkzeug gefunden. Die PHP Foundation sagt es deutlich: “Tools now find bugs faster than ever, for defenders and attackers alike”, Werkzeuge finden Fehler schneller als je zuvor, für Verteidiger wie für Angreifer.

Wenn das Finden und Ausnutzen einer Lücke Stunden statt Monate dauert, schrumpft auch die Zeit zwischen Fix und Angriff. In diesem Fall kamen die ersten Versuche sogar vor dem Fix. Für Engineering-Teams wird Patchen damit von einer gelegentlichen Pflicht zu einem System, das funktionieren muss, bevor die nächste Meldung kommt:

1. Laufzeiten inventarisieren, nicht nur Bibliotheken. composer.json sagt, welche PHP-Versionen Ihr Code akzeptiert, nicht, welches PHP Ihre Server ausführen. Führen Sie eine Liste aller Laufzeiten, Basis-Images und Hosts, jeweils mit Verantwortlichem.
2. Basis-Image-Updates automatisieren. Bauen und rollen Sie Container-Images neu aus, wenn sich das Basis-Image ändert, nicht erst, wenn jemand daran denkt.
3. Eine Konfigurationsänderung in Minuten auf alle Server bringen können. Als einige Stunden lang nur eine Änderung der php.ini half, konnten Teams mit zentraler Konfiguration sie schnell anwenden. Teams, die Server von Hand bearbeiten, nicht.
4. Support-Enddaten im Blick behalten. Laufzeiten nach dem Support-Ende warten auf den Backport eines anderen oder bekommen gar keinen. Der Support für PHP 8.2 endet am 31. Dezember 2026.
5. Die richtigen Signale beobachten. Alarme bei Worker-Abstürzen, Fehlern wegen Speichergrenzen und gehäuften 500-Fehlern hätten diese Angriffe früh angezeigt.

Eine kurze Checkliste für dieses Update

1. Listen Sie jede Stelle auf, an der PHP läuft, einschließlich Container, Hosting und Software mit eingebautem PHP.
2. Aktualisieren Sie PHP auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, oder installieren Sie das korrigierte Paket Ihrer Distribution.
3. Prüfen Sie den Fix, indem Sie im Changelog des Pakets nach den CVE-Nummern suchen.
4. Starten Sie jeden PHP-Prozess neu und prüfen Sie dann die Version, die Anfragen bedient.
5. Bauen Sie Container neu und rollen Sie sie aus, auf Basis eines aktualisierten Basis-Images.
6. Wenden Sie die Notmaßnahmen von PHP an, wo Sie heute nicht aktualisieren können, und planen Sie das Update.
7. Planen Sie den Abschied von PHP 8.1 und älter, und setzen Sie das Upgrade von PHP 8.2 vor dem 31. Dezember 2026 auf den Kalender.
8. Suchen Sie nach Anzeichen einer Kompromittierung ab dem 17. Oktober und tauschen Sie Geheimnisse auf exponierten Servern aus.
9. Benennen Sie einen Verantwortlichen für jede PHP-Laufzeit, damit die nächste Meldung bei einem Menschen ankommt.

Die Regel zum Übernehmen

Jede Laufzeit, von der Ihr Unternehmen abhängt, PHP eingeschlossen, braucht einen benannten Verantwortlichen, ein aktuelles Inventar und einen Weg, jede Instanz innerhalb eines Tages zu patchen, denn die nächste kritische Lücke wird vielleicht von KI gefunden und angegriffen, bevor der Fix erscheint.

Wie Incresco hilft

Incresco ist Claude-Partner. Wir entwickeln Web- und Mobile-Anwendungen, Cloud-Systeme, Salesforce-Lösungen, WhatsApp-Erlebnisse und KI-Agenten, und wir entwickeln und betreuen PHP- und Laravel-Anwendungen. Für Teams, die von PHP2Shell betroffen sind, helfen wir, jede PHP-Laufzeit zu finden, zu patchen und zu prüfen, nach Anzeichen einer Kompromittierung zu suchen und Inventar und Automatisierung aufzubauen, damit der nächste Patch Routine wird. Siehe unsere Leistungen individuelle Plattformentwicklung und Cloud.

Sie wissen nicht genau, welche PHP-Version Ihre Website nutzt oder wer den Server betreut? Sprechen Sie Incresco an und bitten Sie um eine PHP-Patch-Prüfung. Wir prüfen, was Sie heute einsetzen, sagen Ihnen, was zuerst aktualisiert werden muss, und helfen Ihnen, die Lücke zu schließen.

Häufig gestellte Fragen

Was ist PHP2Shell?

PHP2Shell ist der Spitzname für zwei kritische PHP-Sicherheitslücken, CVE-2026-109618 und CVE-2026-109619, die am 21. Oktober 2026 behoben wurden. Beide können einem Angreifer erlauben, ohne Anmeldung Code auf einem Server auszuführen.

Welche PHP-Versionen beheben PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Auch Linux-Distributionen liefern korrigierte Pakete, die eine ältere Versionsnummer zeigen können. Suchen Sie daher im Changelog des Pakets nach den CVE-Nummern.

Behebt ein Update von WordPress oder Laravel die Lücke?

Nein. Die Lücken stecken in der PHP-Engine. Sie müssen PHP selbst aktualisieren, über Ihre Serverpakete, Ihr Container-Image oder Ihren Hosting-Anbieter, und danach jeden PHP-Prozess neu starten.

Was, wenn ich nicht sofort aktualisieren kann?

Die PHP-Meldung nennt vorübergehende Einstellungen, etwa das Abschalten des Session-Upload-Fortschritts und angepasste Grenzen für Speicher und Anfragegröße. Sie verringern das Risiko, machen einen Server aber nicht sicher. Die CISA rät, Systeme vom Netz zu nehmen, die nicht aktualisiert werden können.