News Sofort updaten!: Patches schließen hoch­ris­kante Sicherheitslücken in PHP

[brot-0815]

Appletts

Gibt es doch schon 10 Jahre nicht mehr... aber die PHPest gibt es noch und wird überall eingesetzt.

 

[Fauler_Hund]

@Piktogramm
@Lawnmower
@Relict
Danke für den Input. Inzwischen habe ich allerdings auch eine positive Rückmeldung von Strato bekommen.

 

[Mirlo]

Hier wurde ja schon viel dazu geschrieben ... aber wie sieht es denn jetzt wirklich aus?

Soweit mir bekannt, ist die Lücke per Speicherüberlauf ausnutzbar. Dazu benötigt es in etwa ein Formularfeld. Jedoch keines, was nur von JavaScript genutzt wird, sondern an den Server gesendet wird. Demnach wären nur Websites, bzw. Webhosts und (v)Server betroffen, die ein Formularfeld anbieten. Die erste Frage wäre, ob JavaScript fetch() dabei inkludiert ist oder nicht.

Meine erste Frage dazu ist also: Was benötigt es website-seitig, damit die Lücke ausgenutzt werden kann?

Rein theoretisch auf Level Zero Trust hätten die Webhoster und Serverbetreiber alle Websites mit einem ältreren (cleanen) Backup überspielen müssen. Aber da ist die Frage, seit wann die Lücke irgendwem bekannt sein könnte. Da dies rein theoretisch "schon immer" sein kann ... denn dann könnten auch die Backups kompromitiert sein.

So gesehen ist es also notwendig, dass jeder Webhost, der per PHP im Internet erreichbar ist, bis in die allerletzte Datei im allerletzten Verzeichnis überprüft werden muss.

Die Frage ist nun: Inwieweit ist dieser Aufwand tatsächlich angebracht?

Bei mir tendiert die Lust dazu, alle meine Websites auf Kompromitierung zu überprüfen gegen Null. Zuerst würde ich gerne wissen, wie die Lücke/n ausgenutzt werden können, um dann zu evaluieren, ob meine Websites betroffen sein könnten.

 

[Ranayna]

Dazu benötigt es in etwa ein Formularfeld.

Ich bin kein PHP Experte, und habe mich auch nicht naeher mit der Luecke beschaeftigt.

Aber es gibt ja auch URL Parameter, und ein kurzes Googlen sagt auch, das PHP darauf zugreifen kann.
Das waere also auch ohne Formularfelder ein potenzielles Einfallstor.

 

[Mirlo]

Aber es gibt ja auch URL Parameter

Sogenannter URL-Query-String (/?key=value), der serverseitig per PHP mit $_GET ausgelesen werden kann. Das können Daten aus einem Formular sein, wenn diese per GET gesendet werden. Es kann aber auch ein einfach so erzeugter URL-Query-String sein. Oder Formulardaten per $_POST senden, was empfohlen wird. Aber, damit da-mit ein Speicherüberlauf erzeugt werden kann, muss PHP das serverseitig auch tatsächlich verarbeiten. Ansonsten passiert da gar nichts.

Ich habe ... grübel ... nur eine Website mit einem Formular, dessen Daten per $_POST in PHP verarbeitet werden und diese Website wird dank Google und KI so gut wie nie besucht. Das Risiko ist also sehr gering, bzw. wenn ich ins Tracking schaue gleich Null. Desweiteren habe ich zwei versteckte Websites mit Login-Formularfeld. Zu meinem Nachteil werden diese nicht getrackt. Das Risiko ist bei diesen aber ebenso sehr gering.

... ich kann ja nochmal ins access Log schauen ...

 

[csch92]

hatte das gleiche problem, ging 2-3 tage nicht, seit heute geht es wieder. wohne in kolumbien. ganze zeit 403

Hier funktioniert alles wieder.

 

[AlphaKaninchen]

Was kann schon schiefgehen Browsern vollwertige Anwendungen,

ActiveX war da ja auch so ein Kandidat, im Rückblick alles Wahnsinn, aber in Sachen Sicherheit sind auch heutige Sandboxes nur Kompromisse, zwischen Geschwindigkeit / Bequemlichkeit / Funktionen und Sicherheit. Z.B. JIT ist Klasse für Geschwindigkeit aber wenn man Sicherheit möchte sollte man es lieber deaktivieren...

 

[Aeroway]

Sorry , für einen Laien/mich sind solche News echt eine Kriegserklärung auf kyrillisch oder Klingonentext Ich habe vertrauliche Daten auf Mega und OneDriv e .. Sind die gerade noch sicher? Oder alles herunterladen und löschen?

 

[Web-Schecki]

Aber, damit da-mit ein Speicherüberlauf erzeugt werden kann, muss PHP das serverseitig auch tatsächlich verarbeiten. Ansonsten passiert da gar nichts.

Nein, das ist falsch. Was deine PHP-Skripte verarbeiten, ist vollkommen irrelevant. Es braucht auch kein Formularfeld o.Ä., denn PHP hat mit der Webseite erstmal nichts zu tun.
Der Bug betraf wohl multipart-POST-Anfragen, die die PHP-Runtime unter bestimmten Voraussetzungen nicht richtig behandelt hat. Eine Anfälligkeit gegenüber der Lücke ist also gegeben, sobald eine PHP-Runtime läuft und Anfragen über einen Webserver entgegennimmt. Es muss wohl, je nach Webserver-Konfiguration, nicht mal ein einziges PHP-Skript verfügbar sein, falls z.B. alle *.php-Anfragen direkt an die Runtime gehen und diese dann einen erst 404 generiert und nicht bereits der Webserver (das ist z.B. bei nginx und php-fpm häufig der Fall).

Daher kam es auch zu der ganzen Aufregung gestern. Theoretisch war jede PHP-Installation auf dieser Welt angreifbar. Wie groß die praktische Gefahr war, kann ich aber nicht sagen.

 

[Mirlo]

Der Bug betraf wohl multipart-POST-Anfragen, die die PHP-Runtime unter bestimmten Voraussetzungen nicht richtig behandelt hat.

Es muss wohl, je nach Webserver-Konfiguration, nicht mal ein einziges PHP-Skript verfügbar sein, falls z.B. alle *.php-Anfragen direkt an die Runtime gehen und diese dann einen erst 404 generiert und nicht bereits der Webserver (das ist z.B. bei nginx und php-fpm häufig der Fall).

Für mich ist das ein Widerspruch. Bzw. meinst du damit, dass serverseitig die PHP-Runtime auch bei "*.php" in der URL startet und nicht erst bei "<?php" ? Da kenne ich mich zu wenig mit Servern aus. Kann sein, dass manche das so machen, insbesondere bei verschachteltem PHP in HTML, damit die PHP-Runtime nicht stetig ein- und ausgeschalten wird. Da ist mir etwas in Erinnerung, das php-fpm das so macht?

Aber, dadurch wird nur die PHP-Runtime gestartet, aber keine eingehenden Daten verarbeitet, die wegen ihrer Menge einen Speicherüberlauf erzeugen würden.

"multipart-POST-Anfragen" sind nichtig, solange sie nicht per $_POST verarbeitet werden. Oder willst du damit sagen, dass die Server die POST-Daten ohne $_POST verarbeiten? Aber wie checken sie, ob die Daten valide sind? Das wäre ja ein offenes Scheunentor. Das wäre ja fast so, als wenn in jeder PHP-Datei ein eval($_POST) stehen würde.

Habe mal bei mir in den Zugriffslogs nachgesehen. Am 21.10.2026 gab es bei den Websites/pages mit Formularen um 11:00++ und 23:00++ Auffälligkeiten. Da es aber den Infos nach tausende Requests braucht ... es waren nur um die jeweils 20. Oder sie hatten es bereits bei 20 geknackt?

Ergänzung (Freitag um 00:07)

Hetzner schreibt:

Grundsätzlich empfehlen wir Ihnen, Ihre Systeme sorgfältig auf verdächtige Aktivitäten und mögliche Anzeichen eines Angriffs zu überwachen.

https://status.hetzner.com/de/incident/f4144d55-38c3-48d1-8664-7a3429355cd7

 

[Web-Schecki]

Bzw. meinst du damit, dass serverseitig die PHP-Runtime auch bei "*.php" in der URL startet und nicht erst bei "<?php" ?

Selbstverständlich. Das dürfte auch der Standardfall sein, wobei ich nicht hundertprozentig sicher bin, wie genau es bei apache2 und mod_php läuft. Es gäbe Gründe, apache die Dateien interpretieten zu lassen, um z.B. SSI ausführen zu können. Ich glaube aber, das entsprechende Modul greift auch nur bei .shtml-Dateien, und in jedem Fall wäre es aus Performancegründen extrem nachteilig, weswegen ich davon ausgehe, dass .php-Dateien komplett an die PHP-Runtime übergeben werden. Die Datei muss aber aber zumindest existieren, sonst wirft apache2 bereits einen 404.

Aber, dadurch wird nur die PHP-Runtime gestartet, aber keine eingehenden Daten verarbeitet, die wegen ihrer Menge einen Speicherüberlauf erzeugen würden.

Die Runtime muss logischerweise bereits beim Aufruf alle Eingabedaten verarbeiten, damit das auszuführende Skript dann darauf ausgeführt werden kann. Dein Skript kann leer sein; die Runtime wird immer, sobald sie mit den ganzen Eingabedaten vom Webserver aufgerufen wird, diese zunächst verarbeiten und erst am Schluss dieser Verabreitung das eigentliche Skript interpretieren und ausführen. Bevor auch nur eine Zeile deines PHP-Codes (falls vorhanden) ausgeführt wird, passieren schon sehr viele Schritte, die du nicht explizit veranlasst hast. Eben damit du auf sessions und globale Variablen wie $_SERVER, $_POST usw. zugreifen kannst.

Oder willst du damit sagen, dass die Server die POST-Daten ohne $_POST verarbeiten?

Logischerweise ist das notwendig. Wie willst du sonst über ein assoziatives Array auf die Daten zugreifen? Der PHP-Interpreter muss die Nutzdaten, die erstmal nur einen Bytestrom darstellen, der vom Webserver an irgendeine Speicheradresse geschrieben wird, entsprechend parsen und ggf. in neuer Form im Speicher ablegen. Du willst ja per $_POST["key"] auf den dazugehörigen Wert, der eingegeben wurde, zugreifen können.

Das wäre ja fast so, als wenn in jeder PHP-Datei ein eval($_POST) stehen würde.

Ähm.. Nein.

 

[brot-0815]

Privat läuft in meinen Containern nichts PHP-basiertes mehr, das über meine Subdomains erreichbar ist. Die PHP-Version einer von mir betreuten Website habe ich gestern aktualisiert.

Das ist bei mir auch so. Ich habe einige "Subdomain-Systeme", die aber größtenteils *nicht* auf PHP-Diensten basieren - und falls doch, sind diese bereits aktualisiert. Jedes "Subdomain-System" läuft dabei in einem eigenen Docker-Container. Das heißt, selbst wenn ein Container kompromittiert werden sollte, ist der Schaden relativ überschaubar. Oftmals haben die Container sogar nicht mal gemountete Volumes. Ich kann also einfach das neuste "latest" (oder "stable") Image pull'en und der Container wäre wieder in einem absolut unberührten Initialzustand.

Leider brauche ich für einen privaten Web-Kalender NextCloud... - es gibt praktisch keine sinnvolle Alternative dazu, die einen vernünftigen Kalender mit Web-Oberfläche bietet - und NextCloud setzt wiederum intern auf PHP... Jetzt könnte man sagen, ein "Aggressor" könnte lediglich an ein paar Termine gelangen oder einen zusätzlichen Benutzer anlegen, aber so ein Szenario ist ja einfach durch ein Update vermeidbar.

Ergänzung (Freitag um 02:01)

Habe mal bei mir in den Zugriffslogs nachgesehen. Am 21.10.2026 gab es bei den Websites/pages mit Formularen um 11:00++ und 23:00++ Auffälligkeiten. Da es aber den Infos nach tausende Requests braucht ... es waren nur um die jeweils 20. Oder sie hatten es bereits bei 20 geknackt?

Das ist unwahrscheinlich. Nach allem, was ich hörte, werden tausende Versuche/Anfragen/Requests benötigt, um den Speicherüberlauf zu triggern.

 

[Ranayna]

Es wurde eine Vorabversion an bestimmte Firmen vergeben

HPE wusste auf alle Faelle bescheid. Gab heute Nacht ein Advisory hinsichtlich PHP2Shell bei einigen ihrer Produkte.
Die Softwareversionen auf die geupdatet werden soll, sind teils fast zwei Wochen alt.

 

[kim88]

Ich versuche, ein paar Punkte zu klären, weil sich hier einige Annahmen eingeschlichen haben.

1. Es braucht kein Formular

Die Lücke (CVE-2026-109618 und CVE-2026-109619) steckt in PHP selbst, nicht in einer Anwendung. Sie greift in dem Moment, in dem PHP einen multipart POST Body einliest, also bevor auch nur eine Zeile des eigentlichen Skripts ausgeführt wird. Ob auf der Website ein Formular oder ein fetch() existiert, spielt keine Rolle. Ein Angreifer baut den Request selbst und schickt ihn direkt an eine beliebige PHP Datei.

2. $_POST ist nicht der Auslöser

$_POST ist kein Befehl, der das Einlesen startet, sondern nur das fertige Ergebnis. PHP liest den Request Body standardmässig beim Request Start automatisch ein und füllt $_POST und $_FILES, egal ob das Skript diese danach verwendet. Darum liegt ein Upload schon im temp Verzeichnis, bevor das Skript läuft. Mit eval() hat das nichts zu tun: Die Daten werden nur geparst, nicht ausgeführt. Der Fehler liegt im Ablauf dieses Parsens. Ein gezielt gebauter Request bringt PHP dabei ans Speicherlimit. Der Abbruch hinterlässt den Worker in einem kaputten Zustand, den ein folgender Request ausnutzen kann. Verstärkt wird das durch session.upload_progress, das schon während des Einlesens in die Session schreibt und standardmässig aktiv ist.

3. Warum nicht einmal ein existierendes Skript nötig ist

Der Webserver entscheidet anhand der URL (z. B. \.php$ bei nginx), ob ein Request an php-fpm geht, nicht anhand von <?php in der Datei. Ohne try_files $uri =404; reicht nginx auch Requests auf nicht existierende .php Dateien an php-fpm weiter, und erst PHP liefert dann den 404. Der Body wird in dem Fall trotzdem verarbeitet.

 

[Mondgesang]

irgendeiner Form auf PHP setzen

Meine von Hand gebaute HTML/CSS Seite setzt auf PHP, aber ich glaube nicht auf eine Art und Weise, wie es normalerweise gedacht war.

Da ich faul bin und gewisse Contents auf mehrere meiner Seiten oder Bereiche "projiziere", habe ich eine einzige Datei mit einem bestimmten Inhalt (z.B. eine Auflistung) und diese include ich in andere Bereiche mittels <?php include "/.../...termine.php" ?>. Auch kann ich so ganze Bestandteile der Website nur an einer Stelle einmal bauen und sie dann in alle weiteren Seiten includen. Quasi wie ein Homepage Baukasten nur zu Fuß.

 

[ed_lumen]

mein hoster hat seine arbeit getan, aber der urheber meines CMS, der werweißwo im cyberuniversum lebt, hat bis heute morgen nichts von PHP2Shell gehört. muß ich mir noch immer sorgen machen?

 

[brot-0815]

muß ich mir noch immer sorgen machen?

Es kommt darauf an, ob dein CMS PHP verwendet, also wie die Website ausgeliefert/bereitgestellt wird. Meine wird mit Python gebaut und von einem Apache2 ohne PHP bereitgestellt, und enthält keine "Dynamik" - also keine vollwertige Datenbank, keine Echtzeitgenerierung der Seiten und keine serverseitigen Skripte bzw. Logik.

 

[Web-Schecki]

muß ich mir noch immer sorgen machen?

Ja, aber nicht wegen des PHP2Shell-Bugs, wenn dein Hoster diesen gepatcht hat. Ein CMS einzusetzen, das nicht gut gepflegt wird, ist dennoch gefährlich. Die meisten Sicherheitslücken im Zusammenhang mit Webanwendungen entstehen nicht durch Fehler der PHP-Runtime wie bei PHP2Shell, sondern durch schlecht programmierte PHP-Anwendungen.

 

[ed_lumen]

aktuell benutzt mein CMS PHP Version 8.5.12-nmm1 - dann wohl doch gut in schuß.

 

[Web-Schecki]

dann wohl doch gut in schuß

Nein, das zeigt nur, dass dein Hoster den PHP-Patch installiert hat. Das wusstest du ja aber schon.
Es sagt nichts über die Wartungsqualität des CMS aus.