Problem Highligt der Woche; der Kaffee ist alle, das Wochenende schon halb in Sicht (man schielt voller Vorfreude auf den Vize-Freitag) und plötzlich brennt die digitale Hütte so richtig.
Wenn das Bundesamt für Sicherheit in der Informationstechnik (BSI) und internationale Behörden im Gleichtakt Alarm schlagen und wie in diesem Fall sogar dazu raten, Server lieber erstmal komplett vom Netz zu nehmen, dann wissen wir: Hier handelt es sich nicht um ein kleines Schönheitsfehlerchen im CSS, sondern um den ultimativen IT-Supergau.
Der Name des Schreckens, der gerade durch die Admin-Foren und Nachrichten geht, lautet PHP2Shell. Schauen wir uns mal an, warum weltweit gerade Millionen Webseiten-Betreiber ins Schwitzen kommen, warum Regierungsbehörden vorsorglich den Stecker zogen und was das Ganze technisch unter der Haube bedeutet. Möglichst verständlich für Neulinge und trotz allem mit genug Tiefgang für die Profis.
Was ist überhaupt passiert?
PHP ist das unsichtbare Arbeitstier des Internets. Rund 70 % aller Websites weltweit nutzen es. Angefangen bei der kleinen WordPress-Seite privat über die der Kaninchenzüchter HappyHoppel eV. (verzeiht mir bitte wenn es euch wirklich gibt, der Name kam gerade spontan aus der Bierlaune heraus) bis hin zu fetten E-Commerce-Systemen und globalen Backend-Diensten, sie alle laufen auf Basis dieser Programmiersprache.
Unter den Kennungen CVE-2026-109618 y CVE-2026-109619 wurden im Kern von PHP gravierende Sicherheitslücken entdeckt, die vom PHP-Projekt selbst und externen Experten (wie dem Sicherheitsdienstleister Wiz o die Jungs und Mädels bei calif.io) mit einem CVSS-Schweregrad von 9,2 (kritisch) eingestuft wurden. Das Besondere und Erschreckende daran: Angreifer können über diese Lücken ohne jegliche vorherige Anmeldung (unauthentifiziert) aus der Ferne eigenen Schadcode auf den Webservern ausführen (Remote Code Execution, kurz RCE).
Im Klartext: Wer die Lücke ausnutzt, übernimmt im schlimmsten Fall die komplette Kontrolle über die Kiste, zieht Datenbanken leer oder missbraucht den Server für weitere Angriffe. Das BSI stufte die Cybersicherheitswarnung (Aktenzeichen BITS-H Nr. 2026-297981-1032) hoch ein (orange) und betonte das enorme Schadenspotenzial.
Der technische Blick unter die Haube: Was macht PHP hier eigentlich falsch?
Für alle Code-Junkies und System-Geeks wollen wir kurz in die tiefe Technik eintauchen. Warum kracht es im Gebälk? Die Schwachstellen wurzeln tief im Speicher- und Ausführungsmanagement von PHP:
CVE-2026-109618 (Speicherbereinigung & Fehler-Handling): Wird die Ausführung einer Web-Anfrage beispielsweise durch ein überschrittenes Speicherlimit oder fatale Fehler in Callbacks, Uploads oder Importen abrupt abgebrochen, bleiben interne Datenstrukturen oft unvollständig initialisiert.
Bei der anschließenden Speicherbereinigung (Garbage Collection) greift das System im worst case auf ungültige oder bereits freigegebene Speicherbereiche zu. Kriminelle können dies gezielt triggern, um den Programmfluss zu manipulieren.
CVE-2026-109619 (Veraltete Zustandsinformationen / Use-After-Free): Hier geht es um veraltete interne Zustandsinformationen. Nach der Freigabe eines Speicherbereichs bleiben Zeiger (References) unter bestimmten Bedingungen erhalten.
Wenn Angreifer diesen Mechanismus aushebeln, können sie manipulierte Daten einschleusen, die vom Interpreter als valide Befehle interpretiert werden. Oops!
Besonders brisant ist hier: Betroffen sind diverse Schnittstellen und Webserver-Module wie PHP-FPM, LiteSpeed, FrankenPHP, php-cgi oder Apache mit mod_php. Gerade bei Konfigurationen mit mod_php haben Sicherheitsanalysen gezeigt, dass Angriffe noch vor dem eigentlichen Anwendungscode (also vor jedem CMS-Framework wie WordPress) greifen können. Eine einzige präparierte HTTP-Anfrage reicht aus. Yay!
Laut Berichten reicht die Historie der anfälligen Versionen je nach Einschätzung der Analysten tief in ältere Distributionszweige hinein (wobei das PHP-Team offizielle Patches für die aktiv gewarteten Reihen 8.2 bis 8.5 bereitstellte).
Ältere Versionen, die längst ihr End-of-Life erreicht haben, stehen vor einem massiven Problem, da hier oft nur Community- oder Distributions-Backports helfen. Seit dem die Lücke bekannt ist, ist nun aber nicht mehr die Frage ob sondern nur noch wann der eigene Server betroffen sein wird…
Bin ich schon betroffen?
Detektion ist möglich. Denkbar wären plötzlich auftretetende Child-Prozesse unter PHP die verdächtig erscheinen, beispielsweise sh, bash, cmd oder powershell die dort normalerweise nichts zu suchen haben. Mit dem GitHub Tool process-watcher von Flo Roth lässt sich so etwas zB. aufspüren.
In der Praxis bedeutet dies, dass ein PHP-Worker-Prozess etwa php-fpm, php-cgi, php-cgi.exe, httpd oder apache2 einen eher ungewöhnlichen Vorgang einleiten könnte. Achtet deshalb auf:
Shells wie sh, bash, cmd.exe oder powershell.exe
Interpreter wie python oder perl
Download- oder Netzwerk-Tools wie curl, wget, nc oder certutil.exe
Es lohnt sich vermutlich ebenfalls die Befehlszeilen, die Muster für eine „Reverse Shell“ enthalten, genauer zu untersuchen:
/dev/tcp/
fsockopen
mkfifo
Warum gingen Behörden und Webseiten offline?
Weil die Details und erste Proof-of-Concept-Exploits durchgesickert sind und die Uhr tickte, reagierten IT-Verantwortliche weltweit drastisch. In Deutschland schaltete beispielsweise das ITZBund (der IT-Dienstleister des Bundes) vorsorglich Webseiten ab, und auch in Ländern wie den Niederlanden, Frankreich oder Belgien zogen öffentliche Einrichtungen die Reißleine.
Das BSI gab als Ultima Ratio aus: Wer nicht sofort patchen kann, nimmt den Server vorübergehend vom Internet! Besser eine kurzzeitig unerreichbare Website, als eine komplett kompromittierte Infrastruktur, über die sich Hacker im Sekundentakt breitmachen.
Was ist jetzt zu tun? (Der Rettungsanker)
Panik ist wie immer ein schlechter Ratgeber, aber schnelles Handeln überlebenswichtig.
Patchen, patchen, patchen: Das PHP-Entwicklungsteam hat umgehend reagiert und Sicherheitsupdates veröffentlicht. Die offiziellen Versionen, die das Problem beheben, lauten:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
- (Für ältere Versionen muss geprüft werden, ob der Hoster oder die Linux-Distribution entsprechende Backports/Patches bereitstellt).
Unbedingt die verwendete Version via Befehl php -v prüfen:
Loggt euch auf euren Servern ein und checkt via php -v, welche Version bei euch läuft. Holt euren Hostings-Anbieter ins Boot, falls ihr Managed-Hosting nutzt. Einige der großen haben bereits von sich aus reagiert.
Als Alternative Mitigations-Tricks nutzen (eher eine Notlösung):
Das BSI rät ergänzend dazu, auf Linux-Systemen Sicherheitsfunktionen wie SELinux o AppArmor strikt zu konfigurieren, um den potenziellen Schaden bei einer Remote Code Execution zumindest einzugrenzen. Ein echter Ersatz für das Update ist das aber nicht. Eher ein Pflaster.
Heise hat einige wichige Infos zusätzlich zusammen getragen, die definitiv hilchreich sein können und dem einen oder anderen auch die Augen öffnen wo überall hier eine mögliche Zeitbombe tickt. Ich zitiere hier mal:
Es wird zwar Backports für die Versionen 7.4, 8.0 und 8.1 geben, aber: Wer eine ältere PHP-Version nutzt, sollte die Gelegenheit dringend wahrnehmen und mindestens auf PHP 8.3 schwenken. Während dessen Produktunterstützung noch bis Ende 2027 andauert, geht bei PHP 8.2 bereits Ende 2026 das Licht aus. Wer sich das größtmögliche Zeitpolster schaffen möchte, aktualisiert gleich auf PHP 8.5.12.
Anwendungen, die in Docker-Containern laufen und eine verwundbare PHP-Version mitbringen, sind ebenfalls von den Sicherheitslücken betroffen und sollten schleunigst nach Verfügbarkeit aktualisiert werden (etwa mit „docker compose pull && docker compose up -d“).
Wer seine Webanwendungen bei einem Hoster betreibt, sollte prüfen, ob dieser die Updates zeitnah zu installieren plant, etwa mittels Blick auf die Wartungsseite. Einige der von heise security im Laufe des Mittwochvormittag kontaktierten Hoster waren bereits gewarnt und gaben ihrerseits Warnungen an Kunden ewiter; Uberspace kündigte gar an, PHP-Dienste um 15:45 zeitweise komplett zu deaktivieren. CDN- und Netzbetreiber Cloudflare hingegen hat Regeln für seine Web Application Firewall (WAF) implementiert, die alle bekannten Angriffsvektoren schlössen. Diese Regeln stünden auch Nutzern der kostenlosen Cloudflare-Variante zur Verfügung, seien aber nur ein vorübergehender Flicken, so Cloudflare-CTO Knecht auf Social Media.
Gegenmaßnahmen: Nur Patchen hilft komplett
Das PHP-Team hat eine Reihe von Konfigurationseinstellungen veröffentlicht, die den Missbrauch etwas eindämmen können, warnt aber: „Sie sollten als nichts Anderes als eine temporäre Krücke betrachtet werden“.
memory_limit=-1post_max_sizekleiner als 1/4 des Speicherlimits, hilfsweise 8Mmax_input_nesting_levelauf einen Wert wie etwa 8 beschränkensession.upload-progress.enabled=0- Bei PHP-FPM:
pm.max_requestsauf einen niedrigen Wert festlegen - SELinux / AppArmor nutzen,
- apparmor_hat setzen,
fatal_error_backtraces=0setzen und- con
expose_php=0das Vorhandensein von PHP verschleiern.
Alle Maßnahmen können negative Auswirkungen auf die Geschwindigkeit oder Funktionalität der PHP-Installation haben; sie sollten daher wohldosiert eingesetzt werden. Und: Sie ersetzen keinesfalls ein zügiges Update.
NAS, Appliances und Router auch überprüfen
Nicht nur Web- und Applikationsserver, auch verschiedene vernetzte Geräte nutzen PHP, etwa für ihre webbasierte Verwaltungsoberfläche. All diese Geräte müssen Admins bei der Aktualisierung im Blick haben, etwa von folgenden Herstellern (Quelle)
- pfSense
- OPNsense
- QNAP NAS
- DrayTek
- ZyXEL
- D-Link
- TP-Link
- Netgear
- Tenda
- Synology
Auch Security-Appliances der Hersteller Citrix, Palo Alto und Ivanti nutzen PHP, sowie BIGIP-Loadbalancer von F5. Netzwerkverwalter sollten sie als Teil der Angriffsfläche, nicht als Teil der Verteidigungsmaßnahmen begreifen, sofern die Management- oder Webinterfaces zum Internet hin geöffnet sind.
Wer PHP lediglich für interne Anwendungen verwendet, darf sich dennoch nicht in Sicherheit wiegen. Veraltete PHP-Installationen oder mit PHP ausgestattete Appliances können Angreifern, die etwa über eine Windows-Malware ins Netzwerk eingedrungen sind, nützlich sein, um sich dauerhaft dort einzunisten.
Workarounds Stand 21.10 um 22 Uhr
Nach Angaben der Entwickler kann die Angriffsfläche durch die Umsetzung der folgenden Maßnahmen reduziert, aber nicht vollständig geschlossen werden. Sie liefern somit keinen umfassenden Schutz und sollten daher nur zur Überbrückung der Zeit bis zum Ausrollen des Patches verstanden werden. Alternativ sollte eine Trennung verwundbarer PHP-Systeme vom Internet in Betracht gezogen werden, da Angreifer die genannten Schutzmaßnahmen auf
verschiedene Wege umgehen könnten.
Bei diesen Workarounds handelt es sich um:
CVE-2026-109618
Setzen Sie memory_limit=-1, vorzugsweise auf eine Weise, die von Anwendungen nicht überschrieben werden kann, beispielsweise über php_admin_value in der FPM-Pool- oder Apache-Konfiguration. Prüfen Sie, dass keine Pool-, Verzeichnis- oder Anwendungseinstellung erneut ein endliches Speicherlimit festlegt. Dadurch wird der Fehler aufgrund eines kontrollierbaren PHP-Speicherlimits vermieden. Ein Fehler bei der zugrunde liegenden Speicherzuweisung kann jedoch weiterhin den verwundbaren Codepfad erreichen.
Setzen Sie einen niedrigen Wert für post_max_size. Für Anwendungen, die keine Datei-Uploads benötigen, verwenden Sie post_max_size = 8M. Sind Datei-Uploads erforderlich, verwenden Sie post_max_size = 32M. Achten
Sie darauf, dass upload_max_filesize unterhalb von post_max_size liegt. Erwägen Sie, zusätzlich auf Webserveroder Proxy-Ebene Beschränkungen für die Größe dekodierter Anfragen, die Anzahl der Eingabefelder, die Anzahl
der Multipart-Teile, die Anzahl der Header und die Verschachtelungstiefe durchzusetzen. Diese Beschränkungen müssen auch Anfragen ohne einen verwertbaren Content-Length-Header abdecken.
Verwenden Sie eine Begrenzung auf Container- oder cgroup-Ebene als Schutzmaßnahme zur Sicherstellung der Verfügbarkeit. Bevorzugen Sie dabei eine Richtlinie, die nur den betroffenen Worker beendet. Verwenden Sie
nicht RLIMIT_AS oder RLIMIT_DATA als Ersatz, da diese den anfälligen Fehler bei der Speicherzuweisung auslösen können.
CVE-2026-109619
Setzen Sie session.upload_progress.enabled=0 und starten Sie alle Worker neu. Verwenden Sie eine php.ini-Datei, einen FPM-Pool oder eine Serverkonfiguration, die bereits vor der Verarbeitung von Anfragen greift. Verlassen Sie sich nicht auf ini_set() oder FPM-.user.ini. Dadurch werden die bestätigten Angriffspfade über Sessions blockiert, nicht jedoch andere Varianten.
Setzen Sie unter PHP 8.5 fatal_error_backtraces=0 und starten Sie alle Worker neu. Dadurch wird ausschließlich der bestätigte Angriffspfad über Backtraces bei fatalen Fehlern blockiert.
Entfernen Sie ungültige oder veraltete Einstellungen, die pro Anfrage angewendet werden und vor der Initialisierung Diagnosemeldungen auslösen. Das Unterdrücken dieser Meldungen mit error_reporting, display_errors oder @ hilft nicht.
Beheben Sie fatale Fehler und Zeitüberschreitungen, die von Angreifern ausgelöst werden können. Dazu gehören Fehler in Callbacks, bei der Verarbeitung von Uploads oder Importen sowie bei Bereinigungsprozessen.
Importante:
Alle Workarounds müssen umgesetzt werden, um eine Ausnutzung maßgeblich zu erschweren. Weitere Informationen können zudem den GitHub Advisories entnommen werden [GIT26a][GIT26b].
conclusión
PHP2Shell zeigt mal wieder eindrucksvoll, wie verletzlich das Fundament des modernen Webs sein kann. Wenn ein Kernbaustein wackelt, brennt global die Hütte. Für Admins heißt es jetzt: Kaffeetasse auffüllen, Update-Routinen starten, Logfiles prüfen und sicherstellen, dass die eigene Web-Architektur auf dem neuesten Stand ist.
Und ja, wie Murphy oder Moore’s Law als Konstante im Universum gibt es natürlich auch einen passenden XKCD Comic.
Zusätzliche Quellen: watchtowr.com | sansec.io | huntress.com | golem.de