php2shell-Patches sind nun für PHP 5.2 bis 8.1 verfügbar

Wichtigste Erkenntnisse

• „php2shell“ ist die Bezeichnung für zwei kritische RCE-Sicherheitslücken im PHP-Kern, CVE-2026-109618 und CVE-2026-109619.
• PHP hat diese Fehler in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 behoben, aber für Zweige, deren Lebenszyklus abgelaufen ist, gibt es keinen Upstream-Patch.
• Bereits vor der Veröffentlichung wurden Angriffsversuche gemeldet. Installieren Sie daher jetzt den Patch und starten Sie jeden PHP-Worker neu.
• Im Rahmen des „Endless Lifecycle Support“ (ELS) von TuxCare für Laufzeitumgebungen stehen ab sofort korrigierte Builds für PHP-Versionen bereit, deren Lebenszyklus abgelaufen ist.

Die Kurzfassung

Zur Langfassung springen ↓

Was es ist: „php2shell“ ist der Spitzname, den Forscher den Schwachstellen CVE-2026-109618 und CVE-2026-109619 gegeben haben – zwei kritischen Sicherheitslücken, die die Ausführung von Remote-Code in PHP selbst ermöglichen, nicht jedoch in einem Framework oder CMS. Am 20. Oktober 2026 sickerten Informationen darüber vor der geplanten Veröffentlichung durch, woraufhin das PHP-Sicherheitsteam die Veröffentlichung seines Notfall-Updates auf den 21. Oktober vorverlegte.

Auswirkung: In beiden Fällen kann ein nicht authentifizierter Angreifer Code als Benutzer des PHP-Workers ausführen, wobei die Ausnutzbarkeit eines bestimmten Servers davon abhängt, wie PHP dort ausgeführt wird. PHP hat eine vollständige RCE-Ausnutzung gegenüber Apache mod_php mit Standardbeschränkungen bestätigt und zudem einen Angriffspfad gegenüber PHP-FPM validiert. Zu diesem Abschnitt springen →

Schweregrad: Das PHP-Sicherheitsteam stuft beide als 9,2 gemäß CVSS v4.0 ein, was „kritisch“ entspricht. Die im Zusammenhang mit der Datenpanne kursierende Bewertung von 10,0 stammte nie von PHP. Zu diesem Abschnitt springen →

Wer ist betroffen: Die Sicherheitshinweise von PHP beziehen sich auf betroffene Versionen in allen vier unterstützten Zweigen, während das durchgesickerte Exploit-Tool angeblich bereits ab Version 5.4.0 funktioniert. Upstream stellt nur Patches für die Versionen 8.2 bis 8.5 bereit, sodass PHP 8.1, 8.0, 7.x und 5.x keine Patches von php.net erhalten. Mallory zählte rund 884.000 Hosts mit Internetanbindung, die eine dieser Versionen verwenden. Zu diesem Abschnitt springen →

Status: Dane Knecht, CTO von Cloudflare, berichtete von frühen Angriffsversuchen auf PHP-Websites am 21. Oktober um 07:43 Uhr UTC, also bereits Stunden vor der Veröffentlichung; wie viele davon erfolgreich waren, ist jedoch unklar. Korrigierte „Endless Lifecycle Support“ (ELS)-Builds für Runtimes, die beide CVEs abdecken, sind ab sofort für jeden nicht mehr unterstützten Zweig von PHP 5.2 bis 8.1 verfügbar.

Machen Sie Folgendes sofort: Ermitteln Sie alle PHP-Installationen, die Sie besitzen – einschließlich der in Anbieter-Software und Control Panels enthaltenen Kopien – und beginnen Sie mit allen Systemen, auf denen Apache mod_php läuft, ohne FPM-Hosts auszulassen. Aktualisieren Sie unterstützte Zweige aus dem Upstream oder Ihrer Distribution und verlagern Sie solche, deren Lebensdauer abgelaufen ist, auf einen festen ELS-Build oder nehmen Sie sie aus dem öffentlichen Internet. Starten Sie anschließend jeden PHP-Worker neu oder ersetzen Sie ihn, da der alte Code weiterhin Anfragen bedient, bis dieser Prozess beendet ist. So sehen Sie, was tatsächlich läuft:

ps aux | grep -E '[p]hp-fpm|[p]hp-cgi|[l]sphp|[h]ttpd|[a]pache2'

Achten Sie beim Durchgehen der Liste darauf, ob PHP-Worker-Prozesse Shells starten oder Download-Tools ausführen. So sieht eine Ausnutzung in der Regel aus.

Zu diesem Abschnitt springen →

Die meisten PHP-Notfälle beginnen mit einer App. Ein WordPress-Plugin, eine Magento-Erweiterung, ein Laravel-Paket, das seit 2019 niemand mehr angerührt hat. Man aktualisiert es, ändert ein paar Geheimdaten und macht weiter. Nichts davon betrifft den darunterliegenden Interpreter.

php2shell funktioniert so nicht. Die Sicherheitslücken liegen im Interpreter, sodass im Grunde „alles, was PHP ausführt“ betroffen ist, und der Patch wird nur für vier gepflegte Zweige bereitgestellt. Wer noch PHP 7.4 in einer veralteten Abrechnungsanwendung einsetzt (und davon gibt es jede Menge), musste feststellen, dass es eine kritische RCE-Sicherheitslücke gibt, für die es niemals einen Upstream-Patch geben wird.

Es gibt noch einen dritten Haken. Diese Sicherheitslücken wurden zunächst als Gerüchte bekannt, bevor sie als Patches veröffentlicht wurden, und Angreifer begannen bereits mit ihren Angriffen, noch bevor die Korrekturen verfügbar waren.

Der aktuelle CVSS-4. 0-Wert des NIST liegt bei 9,2 (kritisch), doch es kursierten auch andere, unbestätigte Zahlen. Am Morgen des 20. Oktober wurde in einem Beitrag auf Hacker News behauptet, dass am Donnerstag, dem 22. Oktober, zwei PHP-Sicherheitslücken bekannt gegeben würden, die eine Remote-Code-Ausführung ermöglichen, mit einem CVSS-Wert von 10,0 bewertet sind und bis zurück zu PHP 5 reichen. Der Verfasser des Beitrags lieferte keine weiteren Beweise außer „Quelle: Vertrau mir, Alter“. Der Beitrag wurde gelöscht, doch Screenshots waren bereits überall zu finden.

Dieses Gerücht verstummte nicht, da watchTowr mitteilte, dass die Informationen echt seien, die Sicherheitslücken unter einer Veröffentlichungssperre stünden und alle bis Donnerstag warten sollten. Um 19:33 Uhr UTC an diesem Abend schickte Jakub Zelenka die Vorabmitteilung des PHP-Sicherheitsteams an php.announce. Darin wurden zwei kritische Sicherheitslücken bestätigt, beide mit einem Schweregrad von 9,2 nach CVSS v4.0, wobei die Veröffentlichung für den nächsten Tag, den 21. Oktober, angesetzt war und man sich das Recht vorbehielt, den Patch früher zu veröffentlichen, falls Details an die Öffentlichkeit gelangen oder Ausnutzungsversuche auftreten sollten.

Das Embargo wurde um einen Tag verschoben, und zahlreiche andere Personen sahen sich dieselben Screenshots an. Am nächsten Morgen um 07:43 Uhr UTC teilte der CTO von Cloudflare mit, dass das Unternehmen erste Angriffe verzeichnete, und die provisorischen WAF-Regeln wurden auf alle Tarife ausgeweitet, einschließlich des kostenlosen Tarifs.

In der Vorabmitteilung von PHP wurden übrigens keine der beiden CVE-Nummern genannt. Die Kennungen tauchten zunächst in den durchgesickerten Unterlagen und in den Berichten von watchTowr auf, und die Sicherheitshinweise von PHP bestätigten sie, als die Korrekturen veröffentlicht wurden.

Vor der Veröffentlichung gab es nur wenige öffentliche Informationen. watchTowr gab an, die Schwachstelle CVE-2026-109618 reproduziert zu haben, Huntress hatte noch keinen Proof-of-Concept erstellt, und laut Sansec zeigte der durchgesickerte PHP2Shell-Screenshot einen Banner, der behauptete, alle Versionen ab 5.4.0 abzudecken. Die beiden PHP-Sicherheitshinweise vom 21. Oktober füllten die meisten Lücken.

109618, „RCE durch OOM-Korruption“, hängt davon ab, wie PHP bei Speicherauslastungsfehlern reagiert. Es verwendet longjmp() um die Anfrage abzubrechen; sollte eine Zuweisung fehlschlagen, während der Speicher der Anfrage erst teilweise initialisiert ist, liest der Shutdown-Code diesen fehlerhaften Zustand später aus oder verzweigt entsprechend. Das mehrteilige Parsing bietet Angreifern verschiedene Möglichkeiten, einen OOM-Fehler auszulösen, während sie scheinbar innerhalb der Grenzen bleiben, beispielsweise durch Teile mit einer unbegrenzten Anzahl von Headern. Bei mod_php geschieht dies alles während der Initialisierung der Anfrage, noch bevor Anwendungscode ausgeführt wird.

CVE-2026-109619, „RCE via stale global state“, ist ein „Use-after-free“-Schwachstelle, die sich über mehrere Anfragen erstreckt. Ein schwerwiegender Fehler, einschließlich eines OOM-Fehlers, kann dazu führen, dass ein persistenter Worker Zeiger auf Speicherbereiche behält, die zu einer bereits beendeten Anfrage gehörten. Eine spätere Anfrage auf demselben Worker greift dann auf diesen veralteten Status zu, bevor er durch die normale Initialisierung zurückgesetzt wird. Die Umsetzung ist zwar aufwendiger, doch PHP hat dennoch eine RCE-Lücke in mod_php bestätigt und den Session-Pfad in PHP-FPM validiert.

Es kommt also darauf an, wie Sie PHP ausführen. mod_php ist in beiden Fällen der schlimmste Fall. FPM beendet einen Prozess, wenn der Start einer Anfrage fehlschlägt, was die sauberste OOM-Abfolge blockiert, aber PHP behandelt ihn dennoch als anfällig. PHP-Calls über „FrankenPHP“ sind wahrscheinlich anfällig für anwendungsunabhängige OOM-Angriffe, ähnlich wie bei mod_php, und LSAPI verhält sich eher wie FPM.

Die Verbindung zum Upload-Fortschritt

Dieser Hinweis auf die Version 5.4.0 erwies sich als guter Anhaltspunkt. Mit PHP 5.4 wurde der Session-Upload-Fortschritt eingeführt, der es einem Skript ermöglicht, abzufragen, wie weit ein Multipart-Upload fortgeschritten ist. Diese Funktion ist standardmäßig aktiviert, und in den PHP-Hinweisen wird sie als kaum genutzt beschrieben. Sie ist zudem ein bestätigter Auslöser für CVE-2026-109619, da sie vor der normalen Initialisierung auf die Session-Verarbeitung zugreift und den Status einer unterbrochenen Anfrage übernehmen kann, ohne session_start() Anruf erforderlich. Die Analyse eines Forschers hatte bereits vor Veröffentlichung der Sicherheitshinweise auf einen „Use-after-free“-Fehler in diesem Codepfad hingewiesen, und damit lag er ziemlich richtig.

Das Deaktivieren der Funktion ist nach wie vor keine Lösung. Gina Banyard vom PHP-Kernteam erklärte bereits frühzeitig, dass das Installieren eines Patches die einzige Abhilfemaßnahme sei, und beide Sicherheitshinweise bestätigen dies, indem sie ein Update als einzige vollständige und zuverlässige Lösung bezeichnen. Das Deaktivieren des Upload-Fortschritts blockiert zwar den demonstrierten Sitzungspfad, jedoch keinen der anderen Lebenszykluspfade.

Falls einige Hosts heute nicht gepatcht werden können, wird die PHP-Notlösung für diesen Pfad aktiviert. php.ini oder ein spontaner Besuch unter conf.d, und Sansec fügt zusätzlich einen strengen Sitzungsmodus hinzu:

session.upload_progress.enabled = 0
session.use_strict_mode = 1

FPM-Pools können die allgemeinen INI-Einstellungen überschreiben. Überprüfen Sie daher die aktuelle Konfiguration jedes einzelnen Pools. Wenn ein Pool eigene Überschreibungsoptionen benötigt, verwenden Sie diese und starten Sie anschließend die Worker des Pools neu:

php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[session.use_strict_mode] = on

Der strenge Sitzungsmodus ist eine PHP-eigene Funktion Leitfaden zur Sitzungssicherheit seit Jahren vorangetrieben hat, sodass die Hälfte davon fast nichts kostet, auch wenn Redis oder Datenbank-Session-Handler die dafür erforderliche ID-Prüfung möglicherweise nicht implementieren. Weitere Übergangslösungen sind unter anderem fatal_error_backtraces=0 unter PHP 8.5 und das Blockieren von Multipart-Anfragen im Frontend, falls die App niemals Uploads akzeptiert. Für CVE-2026-109618 besteht die wichtigste vorübergehende Abhilfemaßnahme in der PHP-Konfiguration darin, Folgendes durchzusetzen: memory_limit=-1 auf administrativer Ebene und durch einen Neustart aller Worker, wodurch die vorhersehbare Begrenzung pro Anfrage aufgehoben wird, auf die sich der bestätigte Exploit stützt. Gehen Sie dabei vorsichtig vor, da dadurch auch die Schutzmaßnahmen von PHP gegen außer Kontrolle geratene Skripte außer Kraft gesetzt werden und PHP angibt, dass diese Lösung noch nicht vollständig ist. Keine dieser Maßnahmen stellt eine endgültige Lösung dar. Betrachten Sie sie als vorübergehende Maßnahmen, bis alle Hosts gepatcht sind.

Warum „End-of-Life“-PHP das größere Problem ist

Die Seite zu den unterstützten PHP-Versionen lässt daran keinen Zweifel. Die Zweige 8.4 und 8.5 werden aktiv unterstützt, 8.2 und 8.3 erhalten nur noch Sicherheitspatches, und alle älteren Versionen sind nicht mehr unterstützt. Für nicht mehr unterstützte Zweige gibt es keine Sicherheitsupdates mehr von php.net, und selbst eine kritische RCE-Sicherheitslücke ändert daran nichts.

Die Zahlen zu den noch im Einsatz befindlichen Systemen sehen nicht gut aus. Mallory zählte am 20. Oktober etwa 884.000 Hosts mit Internetanbindung, deren HTTP-Banner PHP 8.1 oder älter anzeigten – das sind etwa 59 % der Hosts, die überhaupt eine Version angaben. Banner sind kein sicherer Hinweis auf eine Sicherheitslücke, und auf einigen dieser Hosts laufen zurückportierte Pakete. Dennoch ist es eine erschreckend hohe Zahl an Hosts mit Internetanbindung, die veraltetes PHP melden.

Die Installationen, die Probleme bereiten, sind diejenigen, die niemand als PHP-Server betrachtet. Hersteller-Appliances. Windows-Software, die ihre eigene php-cgi.exe (ELS for Runtimes bietet aus genau diesem Grund auch Windows-PHP-Builds an). Control Panels. Ein internes Wiki, das jemand 2017 eingerichtet und seitdem nie wieder erwähnt hat.

Stellen Sie sich eine Agentur mit 30 Mitarbeitern vor, die einige hundert WordPress-Seiten ihrer Kunden auf einem cPanel-Server hostet, wobei die Hälfte der Konten auf PHP 7.4 festgelegt ist, weil ein Premium-Theme unter 8.x nicht mehr richtig funktioniert. Niemand wird all diese Seiten bis Freitag auf PHP 8 umstellen. Ein PHP-Upgrade ist ein Anwendungsprojekt, und genau deshalb laufen immer noch so viele PHP-7.x-Installationen.

Genau diese Lücke soll ELS for Runtimes schließen. TuxCare portiert Sicherheitskorrekturen in End-of-Life-Zweige zurück, sodass eine auf Version 7.4 festgelegte Website den „php2shell“-Patch erhält, ohne dass während einer aktiven RCE-Sicherheitslücke eine erzwungene Migration auf PHP 8 erforderlich ist. Die Migration muss zwar trotzdem erfolgen, sie kann jedoch nach einem Zeitplan durchgeführt werden, den jemand selbst festgelegt hat.

Woher der „php2shell“-Fix stammt, nach Zweig, mit den von PHP selbst angegebenen Unterstützungszeiträumen:

In beiden Sicherheitshinweisen werden die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 als gepatchte Versionen aufgeführt, und im Changelog von PHP finden Sie die Details zu den einzelnen Zweigen. Installieren Sie die entsprechende Version und überprüfen Sie anschließend, ob die Prozesse, die Anfragen bearbeiten, diese tatsächlich ausführen.

Wenn PHP aus den eigenen Repositories Ihrer Linux-Distribution stammt, ist deren Hinweis maßgeblich. Distributionen portieren Korrekturen oft zurück, ohne die Versionsnummer des Upstreams zu ändern, sodass eine Versionsangabe allein keine Aussagekraft hat.

Holen Sie sich ELS für Runtimes noch heute →

PHP gab es schon einmal

Im Mai 2012 wurden Einzelheiten zu CVE-2012-1823 bekannt, einer Sicherheitslücke, die die Ausführung von Code aus der Ferne in php-cgi, wurden versehentlich veröffentlicht, bevor der Patch fertig war. PHP brachte eilig die Versionen 5.3.12 und 5.4.2 heraus. Stefan Esser und andere zeigten schnell, dass der Patch umgangen werden konnte, und PHP musste bereits wenige Tage später erneut eine neue Version veröffentlichen, da Computerworld berichtete damals.

Dann gibt es noch CVE-2024-4577, die Windows- php-cgi Argument-Injection ab Juni 2024. Laut Akamai wurden bereits innerhalb von 24 Stunden nach der Offenlegung Angriffsversuche auf die Honeypots des Unternehmens verzeichnet, Die Hacker-Nachrichten.

Bekannte Sicherheitslücken verkürzen den Zeitplan für alle Beteiligten, einschließlich der Entwickler, die den Patch erstellen, und überstürzte Patches müssen manchmal noch einmal überarbeitet werden. Behalten Sie die Sicherheitshinweise auch noch einige Tage nach der Installation des Patches im Auge.

Beobachten Sie, was PHP erzeugt

RCE auf Interpreter-Ebene sieht in der Regel immer gleich aus, unabhängig davon, wie der Fehler genau funktioniert. Ein PHP-Worker wie beispielsweise php-fpm, php-cgi, lsphp oder ein Apache-Prozess startet etwas, das er normalerweise nie startet. Shells, Python oder Perl, curl oder wget. Befehlszeilen, die /dev/tcp/ oder mkfifo sind klassische Anzeichen für eine Reverse-Shell, ebenso wie ein php -r Aufruf mit einem einzigen Befehl fsockopen. Ein Ausbruch von whoami, id oder uname -a Wenn ein Prozess als Webserver-Benutzer ausgeführt wird, handelt es sich um jemanden, der Erkundungen durchführt. Keines dieser Anzeichen ist für sich genommen ein Beweis, da Admin-Tools teilweise ähnliche Funktionen ausführen. Entscheidend ist ein ungewöhnlicher Prozessbaum, der mit einer Anfrage oder einer gerade erst erstellten Datei zusammenfällt.

Auf Linux-Servern ohne Endpunktüberwachung protokolliert Florian Roths kostenloser Prozessbeobachter jedes Programm, das ein PHP-Prozess startet, einschließlich der vollständigen Befehlszeile. Roth macht deutlich, dass das Tool nichts verhindert – es beobachtet lediglich. Hier ein kurzer Einblick in den aktuellen Stand:

ps -eo pid,ppid,user,args --forest | grep -A3 '[p]hp-fpm'

Sollte sich etwas herausstellen, isolieren Sie den Server und sichern Sie die Webserver- und PHP-Protokolle, bevor jemand „aufräumt“. Ein leeres Zugriffsprotokoll ist kein Entwarnungssignal, da in den Standardprotokollen keine POST-Inhalte erfasst werden. Suchen Sie nach Webshells, neuen Dateien im Web-Stammverzeichnis, neuen Cron-Jobs und neuen Konten. Das Patchen eines kompromittierten Hosts schließt die Tür, während sich der Eindringling noch im System befindet. Wenn ein Patch nicht sofort installiert werden kann, empfiehlt CERT-EU, internetgestützte Anwendungen aus öffentlichen Netzwerken zu entfernen, bis eine Lösung vorliegt. Eine WAF oder ein VPN vor einer alten Niederlassung verschafft Zeit – mehr nicht.

Zunächst wird eine Bestandsaufnahme durchgeführt, und die Liste ist in der Regel länger, als man erwartet. Diese Schleife überprüft die üblichen Linux-Speicherorte sowie ELS-Builds unter /opt/alt/ enthalten und gibt die von jeder Binärdatei gemeldete Version aus. Das ist ein erster Ansatz, da benutzerdefinierte Builds und Anbieter-Bundles an beliebigen Orten gespeichert sein können:

for p in /usr/bin/php /usr/bin/php[0-9]* /opt/alt/php*/usr/bin/php; do [ -x "$p" ] && echo "$p $("$p" -r 'echo PHP_VERSION;')"; done

Das zeigt an, was sich auf der Festplatte befindet, nicht, was auf den einzelnen Websites läuft, da FPM-Pools, virtuelle Hosts und Control Panels jeweils auf eine andere Binärdatei verweisen können. Überprüfen Sie auch diese Konfigurationen. Unterstützte Zweige erhalten das Upstream- oder Distro-Update. ELS for Runtimes führt Updates über den normalen Paketmanager durch, wobei die Befehle aus der PHP-Dokumentation zu TuxCare’s ELS for Runtimes verwendet werden. Auf RPM-basierten Systemen lautet der Befehl „sudo yum update alt-php*“. Unter Debian und Ubuntu aktualisieren Sie die Paketlisten und führen Sie ein Upgrade der alt-php-Pakete durch:

sudo apt-get update
sudo apt-get upgrade alt-php*

Dann der Schritt, der oft übersprungen wird. Die Installation des korrigierten Pakets reicht nicht aus, solange die Worker weiterhin den alten Code ausführen. Ein laufender PHP-FPM-Master oder mod_php wird innerhalb von Apache geladen, hält den alten Code im Speicher, bis Apache neu gestartet wird, und ein Container bewahrt ihn auf, bis er ersetzt wird. Shared-Hosting-Server mit Dutzenden von FPM-Pools sind der klassische Fall, bei dem eine Version neu gestartet wird und drei andere nicht. Überprüfen Sie, ob alle FPM-Master nach der Aktualisierung gestartet wurden:

ps -eo pid,lstart,args | grep '[p]hp-fpm: master'

Schließen Sie das Ticket schließlich nicht aufgrund eines Versionsvergleichs des Scanners mit der Upstream-Version. Ein zurückportiertes ELS oder ein Distro-Build meldet möglicherweise weiterhin die ursprüngliche Upstream-Versionsnummer, sodass Scanner, die nur Versionszeichenfolgen auslesen, bereits gepatchte Hosts als problematisch kennzeichnen können. Sofern Ihre Tools dies unterstützen, speisen Sie ihnen die maschinenlesbaren Sicherheitsdaten von TuxCare ein, darunter OVAL- und CSAF-Feeds. Erfassen Sie das installierte Paket, den entsprechenden Sicherheitshinweis und den Prozess, der tatsächlich Anfragen bedient, denn genau danach wird ein Auditor fragen.

Warum php2shell wichtig ist

Eine Laufzeitumgebung ist eine Abhängigkeit, und wenn sie nicht mehr unterstützt wird, bedeutet dies, dass jede neue Kernschwachstelle auf unbestimmte Zeit ungeschlossen bleibt. Die Teams überwachen ihre Composer-Pakete sorgfältig und führen sie dann auf einem Interpreter aus, für den seit Jahren keine Sicherheitsupdates mehr bereitgestellt werden.

Die Sicherheitslücke zeigte auch, wie wenig Vorwarnzeit man hat. Die ersten Gerüchte bestätigten sich innerhalb weniger Stunden, der Patch wurde am nächsten Tag veröffentlicht, und bereits vor dessen Veröffentlichung gab es erste Angriffsversuche. „Wir werden im nächsten Quartal ein Update durchführen“ – so etwas ist bei einem solchen Zeitplan einfach nicht machbar.

Es gibt nun auch eine Möglichkeit, dies selbst zu implementieren. PHP hat Backports für 7.4, 8.0 und 8.1 in php-src eingepflegt, ohne Releases zu taggen, und Community-Skripte erstellen nun aus diesen Backports neu kompiliertes PHP. Das funktioniert zwar für einen einzelnen, selbst kompilierten Server, behebt jedoch nur das „php2shell“-Problem und nichts danach, überspringt Distributionspakete, `mod_php` und `lsphp` und macht aus jedem zukünftigen PHP-CVE wieder ein Build-Projekt.

Also: Führt jetzt die notwendigen Patches an den unterstützten Zweigen durch und startet alles neu, was neu gestartet werden muss. Was PHP betrifft, das php.net aufgegeben hat, solltet ihr es auf einen stabilen ELS-Build umstellen oder aus dem Internet entfernen – und dann die eigentliche Migration in den Kalender eintragen, statt sie auf einer Wunschliste stehen zu lassen.

Holen Sie sich ELS für Runtimes noch heute →

Zeitleiste

Referenzen

Die wichtigsten Quellen für diesen Beitrag sind die PHP-Sicherheitshinweise „RCE via OOM corruption“ (CVE-2026-109618) und „RCE via stale global state“ (CVE-2026-109619) sowie die Vorabankündigung des PHP-Sicherheitsteams auf php.announce (20. Oktober 2026), die Seite mit den unterstützten PHP -Versionen und das PHP-8-Changelog, die „php2shell“-FAQ von watchTower, die „php2shell“-Forschungsergebnisse von Sansec, der Rapid-Response-Bericht von Huntress, das CERT-EU-Sicherheitshinweis 2026-018, Mallorys Risikoanalyse, Florian Roths „Process-Watcher“, die NVD-Einträge zu CVE-2026-109618 und CVE-2026-109619, die Berichterstattung von „The Hacker News“ sowie die Dokumentation zu TuxCares ELS für PHP-Laufzeitumgebungen.