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

[Fauler_Hund]

@Jan
Mittwald kann man hier nachlesen: https://www.mittwald-status.de/incidents/253273

Die waren n paar Stunden offline. Aber zumindest kann man sich da sicher sein, dass man sich drum gekümmert hat.

Von Strato bin ich persönlich enttäuscht: Das letzte Mal als ich nachgesehen habe (heute früh) hatte ich noch keine Antwort, ob die PHP Lücke bei der Website gepatched wurde. Ergo: Website bleibt offline.

Was die Gefählichkeit der Lücke angeht: Da glaube ich dem BSI mehr als manchen Leuten, die die Sache herunter spielen.

 

[Relict]

Einfach krank wie unsicher PHP ist und immer war.

JEDE Software hat Lücken, Bugs und Unsicherheiten. Was Fachleute aufgrund der immer höheren Komplexität nicht mehr durchblicken und entdecken können, kann heute KI viel effizienter.
Und natürlich auch Hacker, die mit KI für diese gefundenen Lücken zeitnah Scripte schreiben lassen.
DAS ist die Zukunft und wird noch richtig "lustig" werden!

Von Strato bin ich persönlich enttäuscht: Das letzte Mal als ich nachgesehen habe (heute früh) hatte ich noch keine Antwort, ob die PHP Lücke bei der Website gepatched wurde.

Mit phpinfo und bekannter php-Versionsnummer inkl. Build-Date vom Oct 21 2026 ist die Wahrscheinlichkeit extrem hoch, dass gepatched wurde, auch bei älteren 7er Versionen mit inoffiziellen Patches per Backporting/Compile

8.5.12
8.4.27
8.3.36
8.2.35

 

[brot-0815]

Wie prüfe ich anhand der Requests, ob ein Angriff stattfand bzw. ein Exploit genutzt bzw. infiltriert wurde?

Ok... Angriffsversuche gab es im Zeitraum auch:

  RequestPath like '%..%' or
  RequestPath like '%/etc/passwd%' or
  RequestPath like '%php://%' or
  RequestPath like '%eval(%' or
  RequestPath like '%base64_decode%'

aber keiner war erfolgreich:

@StatusCode = 200 and (
  RequestPath like '%..%' or
  RequestPath like '%/etc/passwd%' or
  RequestPath like '%php://%' or
  RequestPath like '%eval(%' or
  RequestPath like '%base64_decode%'
)

Also nach dem Updaten entspannt zurücklehnen.

 

[Lawnmower]

@Fauler_Hund
Grundsätzlich kann man das sehr einfach selber prüfen: .php Datei z.B. info.php erstellen, <?php phpinfo(); ?> reinschreiben, speichern, in den Webroot hochladen und dann im Browser aufrufen. Die PHP Version steht direkt oben.
Gehört sie zu den gepatchten, kann die Webseite online bleiben. Wenn nicht, offline nehmen und prüfen ob man die PHP Version im Hosting Control Panel oder wie auch immer das heisst ändern kann.

@brot-0815 Würde behaupten sowas siehst Du alle Tage, das ist einfach ein Bot der verschiedene Pfade durchprobiert. Von denen gibt es leider viel zu viele die automatisiert Webseite abklopfen.

 

[Piktogramm]

Wie prüfe ich anhand der Requests, ob ein Angriff stattfand bzw. ein Exploit genutzt bzw. infiltriert wurde?

ganz grob:

• Größere HTTP-POST Requests sind verdächtig. Im Detail vor allem wenn die angegebene Größe kleiner ist als der eigentliche Payload
• HTTP-POST als file Upload der Größe 0

Writeup zu Php2shell: https://calif.io/php2shell/

Von Strato bin ich persönlich enttäuscht: Das letzte Mal als ich nachgesehen habe (heute früh) hatte ich noch keine Antwort, ob die PHP Lücke bei der Website gepatched wurde. Ergo: Website bleibt offline.

Wirf halt ein phpinfo() in die Webkonsole, ein .php und schau nach?!

 

[brot-0815]

Würde behaupten sowas siehst Du alle Tage, das ist einfach ein Bot der verschiedene Pfade durchprobiert. Von denen gibt es leider viel zu viele die automatisiert Webseite abklopfen.

@Lawnmower Das stimmt wohl. Ich habe nur kurz die KI gefragt, nach Ausdrücke für ausfällige Muster in den Logs, bezüglich PHP.

 

[Simanova]

Ich würde ja gerne was sinnvolles in diesen Thread schreiben,
hab aber keine Zeit weil ich seit gestern Server am patchen bin.

Ergänzung (22. Oktober 2026)

Wie prüfe ich anhand der Requests, ob ein Angriff stattfand bzw. ein Exploit genutzt bzw. infiltriert wurde?

Ist leider Systemabhängig. Die meisten Firmen nutzen dazu eine zusätzliche Detection & Respone Software. Als Privatanwender kannst du prüfen ob deine Website noch geht, der Admin Zugang noch i.O ist und bei bedarf deine Kennwörter ändern nachdem der Patch eingespielt wurde.

Als Angreifer gibt es 2 Szenarien:

• A) Die Website / den Dienst lahmlegen, in diesem Fall ist deine Website lahm gelegt
• B) Unentdeckt einnisten, in diesem Fall die Benutzerverwaltung auf unbekannte Accounts prüfen und das Admin PW ändern

 

[mblaster4711]

PHP ist ja schon ziemlich altbacken

und trotzdem läuft es zuverlässig.
HTML ist noch älter.
Aber beides wurde in den vergangenen Jahren immer wieder Stück für Stück modifiziert.

 

[gunmarine]

Hallo ist das der grund warum ich aktuell ohne vpn nicht auf conputerbase zugreifen kann? Leben in Norwegen und da kommt ne fehlermeldung.
Ist aktuell die einzige seite die nicht funktioniert

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

 

[Steffen]

Die Maßnahmen waren keine 24h aktiv.

Siehe: https://www.computerbase.de/forum/t...mputerbase-via-vpn-etc-am-21-10-2026.2280518/

 

[fdsonne]

Persistieren und Rechteausweitung schön und gut, in dem Moment wo die Shell zur Verfügung steht können Angreifer beliebig Code ausführen. Bis zum nächsten Neustart hat man auf jeden Fall einen Knoten fürs eigene Botnetz. Wobei viele Container für Webanwendungen oftmals irgendwie schreiben können müssen um Aktualisierungen des Inhalts entgegenzunehmen.

Kontext?
Was möchte deine Ausführung jetzt sagen?

Wir kamen vom potentiell infizierten Host - in Zeiten von Containern wahrscheinlich in vielen Fällen ein Container. Der Versuch des Findens einer Infizierung ist häufig relativ schwer, den Container in einer ab dem Zeitpunkt gepatchten Version einfach neu zu bauen und zu starten behebt das Problem wirkungsvoll. Es ist aktuell kein Ausbruchsszenario über das Ansammeln verschiedener Angriffe bekannt. Wenn dir eins bekannt ist, berichtige mich gern mit einem Link zu den Fakten. Ansonsten ist sowas wie so oft hypothetische Panikmache wie da oben mit CVE-2026-99999 genannt wurde . Du kannst natürlich auch alles löschen und neu beginnen - wirkt natürlich auch.

Ich zweifle am Sachverstand von Admins, wenn sie ihre Maßnahmen als derart sicher beschreiben.

Viel mehr Sicherheit als den vollständigen Schutz vor allen bekannten Sicherheitslücken kann man nicht haben. Ein gescheiter Admin ist sich dem bewusst. Nichts desto trotz sollten entsprechende Maßnahmen ergriffen werden um nicht fahrlässig unnötige Angriffsvektoren zu öffnen, die vermeidbar sind. Ich verstehe deinen Einwand nicht. Das klingt als könne ein Admin nicht ruhig schlafen weil ja was sein könnte? Oder wo soll ein Admin sich über sein tun nicht sicher sein dürfen?

 

[brot-0815]

Die meisten Firmen nutzen dazu eine zusätzliche Detection & Respone Software.

Das ist leider Wunschdenken:

Übersicht mit KI

Für die brandneue, am 21. Oktober 2026 veröffentlichte PHP-Sicherheitslücke „php2shell“ (CVE-2026-109618 und CVE-2026-109619) gibt es zum aktuellen Zeitpunkt noch keinen fertigen, vollautomatischen Log-Analyzer.
Da Angreifer bei einem erfolgreichen Exploit oft direkt Berechtigungen des Web-Worker-Prozesses erlangen und Spuren verwischen können, konzentriert sich die Community derzeit auf das manuelle Threat Hunting anhand bestimmter Verhaltensmuster sowie auf externe Scans.
Um herauszufinden, ob Sie betroffen sind oder bereits angegriffen wurden, sollten Sie folgende Schritte...

Das heißt, man muss selber manuell prüfen. Zuerst die Version, und dann auf kompromittierte IoCs (Log-Analyse: Gehäufte Speicherfehler, Cookies, Kindprozesse und neue Dateien).

Aufatmen lässt aber, dass oft tausende Versuche benötigt werden, um den Speicherüberlauf zu triggern.

 

[Haxor]

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.

PHP ist wie Java. Jedes Jahr wir gesagt Java stirbt aus... ähm ja.

Wo wird denn behauptet, dass Java stirbt? Das höre ich tatsächlich zum ersten Mal. Allein aufgrund der enormen Verbreitung im Enterprise-Umfeld und der gewachsenen Ökosysteme wird Java nicht so schnell verschwinden.
Spring Boot, Jakarta EE und Apache Hadoop sind nur einige Beispiele aus dem Java-Ökosystem. Dazu kommt, dass neben Java auch zahlreiche andere Sprachen und Frameworks auf der JVM laufen, darunter Kotlin und Scala. Auch Technologien wie Apache Spark setzen auf die JVM.

Vielleicht macht es Sinn jede Mensch-Computer-Mensch Sprache abzuschaffen und die KI soll einfach eine selbst erfinden.

Wie soll ein Mensch unabhängig überprüfen, was die KI tatsächlich programmiert hat, wenn sowohl die Programmiersprache als auch deren Interpretation von der KI selbst stammen? Ohne eine standardisierte Semantik, eine unabhängige Verifikation und eine nachvollziehbare Darstellung?
Dass Sprachen wie Rust durch den niedrigschwelligen Zugang via Vibe Coding künftig an Verbreitung gewinnen, halte ich aber durchaus für wahrscheinlich.

 

[brot-0815]

Wo wird denn behauptet, dass Java stirbt?

Ich verstehe das Java Bashing auch nicht... das von PHP hingegen schon...

Java/JVM Entwickler machen eben ihre Hausaufgaben... das kann man von dem vielen anderen Pfusch nicht behaupten.

Nach den Ereignissen heute und gestern sollte eigentlich klar sein, dass PHP nicht "das goldene Pferd" ist... Aber na ja, es wird immer so weitergehen.

 

[.one]

Ihr macht da echt ein Fass auf... Das Stopfen der Lücke (Arbeit gegen die KI) hat nun wie lange gedauert? Aber fleißig Microsoft nutzen. Ihr macht das schon...

 

[brot-0815]

Das Stopfen der Lücke (Arbeit gegen die KI) hat nun wie lange gedauert?

Die Lücke war schon länger bekannt (durch KI...), wurde dann gefixt (auch mithilfe von KI...) und sollte eigentlich stillschweigend für alle gleichzeitig ausgerollt werden - wenn es nicht vorher diesen Leak gegeben hätte, wodurch viele in (berechtigte) Panik verfallen sind.

KI findet (und behebt) mittlerweile Fehler, die jahrzehntelang nicht auffielen... (Agenten können diese auch nutzen, aber das ist jetzt hier nicht das Thema...) Das sollte etwas zu denken auf geben, und spricht nicht gerade für php's Robustheit. Und das ist ja nicht der erste Vorfall, alles find mit sql injection an.

 

[Haxor]

Nach den Ereignissen heute und gestern sollte eigentlich klar sein, dass PHP nicht "das goldene Pferd" ist... Aber na ja, es wird immer so weitergehen.

Ich bin auch kein großer PHP-Fan, aber auch in der JVM gabs schon zahlreiche Sicherheitslücken.
Viele kritische Sicherheitslücken in Runtimes haben ihre Ursachen in den typischen Speicherfehlern von C und C++ – hat schon seine Gründe, warum die Industrie zunehmend auf Rust setzt. Als ich im Grundstudium war, wurde im Modul Betriebsysteme alles in C programmiert (z.B. ein Scheduler), am Ende meines Bachelors wurde im selben Modul schon alles in Rust umgesetzt.

 

[ed_lumen]

all-inkl. schreibt:

Warnung​

Kritische Sicherheitslücken in PHP – Sicherheitsupdates eingespielt

Am 21.10.2026 wurden zwei kritische Sicherheitslücken in der Programmiersprache PHP veröffentlicht, die unter bestimmten Umständen einen unberechtigten Zugriff auf Webserver ermöglichen könnten.

Wir haben unmittelbar reagiert und bereits vor Veröffentlichung der Sicherheitsupdates zusätzliche Schutzmaßnahmen auf unseren Servern aktiviert.

Inzwischen haben wir sämtliche bei uns angebotenen PHP-Versionen mit den notwendigen Sicherheitskorrekturen versehen. Dies gilt auch für ältere PHP-Versionen, die vom PHP-Projekt offiziell nicht mehr unterstützt werden.

Zum Schutz unserer Infrastruktur und Ihrer Daten haben wir außerdem vorsorglich einige unserer eigenen Dienste vorübergehend abgeschaltet. Diese werden nach Abschluss der Sicherheitsprüfungen wieder vollständig zur Verfügung gestellt. Die Webseiten unserer Kunden waren von diesen Abschaltungen nicht betroffen.

Nach unserem bisherigen Kenntnisstand liegen uns keine konkreten Hinweise auf eine erfolgreiche Ausnutzung der Sicherheitslücken auf unseren Systemen vor. Eine Ausnutzung vor Installation der Sicherheitsupdates lässt sich jedoch nicht grundsätzlich ausschließen.

Wir empfehlen Ihnen daher, Ihre Webseiten und Anwendungen auf ungewöhnliche Veränderungen zu überprüfen, insbesondere auf unbekannte Dateien, unerwartete Änderungen oder neu angelegte Benutzerkonten.

Unsere Techniker überwachen die Systeme weiterhin und prüfen auffällige Aktivitäten.

Weitere technische Informationen finden Sie in der offiziellen Sicherheitsmeldung des PHP-Projekts.

 

[Ranayna]

Ich bin auch kein großer PHP-Fan, aber auch in der JVM gabs schon zahlreiche Sicherheitslücken.

Bei Java muss ich immer noch an Appletts denken.
War sicherheitstechnisch so eine richtig gute Idee
Was kann schon schiefgehen Browsern vollwertige Anwendungen, anfangs ohne wirkliche Sandbox oder Isolierung, einfach kommentarlos starten zu lassen

 

[.one]

Die Lücke war schon länger bekannt (durch KI...),

Nein, die Lücke war den Programmierern bekannt und es wurde schon lange an einem Fix gearbeitet. Es wurde eine Vorabversion an bestimmte Firmen vergeben (ist so üblich) und dort wurde genau diese (nicht fertige Version) geleakt.