PHP-Panik: Zwei kritische Lücken gefährden 70 % des Internets – und alle flippen aus

Wenn Sie heute überhaupt online waren, haben Sie die Panik mitbekommen: Eine kritische Schwachstelle droht, so ziemlich jede Website auf dem Planeten zu „pwnen“.

Finnland hat am Mittwoch gerade damit begonnen, Regierungswebsites abzuschalten, die NSA empfiehlt allen Organisationen, die PHP verwenden, ihre Websites abzuschalten, und die Niederlande und Frankreich taten dasselbe. Und nein, es war kein Cyberkrieg.

Der Übeltäter war PHP, eine Programmiersprache, von der die meisten Menschen noch nie gehört haben. Sie haben sie heute aber fast sicher verwendet: Sie läuft laut W3Techs auf etwa 70 % aller Websites, deren serverseitige Sprache bekannt ist.

PHP ist die Software, die hinter den Kulissen auf dem Server einer Website arbeitet – dem Computer, der die Website speichert und jede Seite erstellt, die Sie anfordern. Jede WordPress-Website zum Beispiel läuft auf einem PHP-Server, so die WordPress-Sicherheitsfirma Wordfence.

Oh, übrigens, Wordfence ist auch down.

Zwei neu entdeckte Fehler in PHP selbst ermöglichen es einem Fremden, seine eigenen Befehle auf diesem Server auszuführen, ohne sich jemals anzumelden. Sicherheitsexperten nennen das unauthentifizierte Remote-Code-Ausführung. Alle anderen können es nennen: „Jetzt fährt jemand anderes.“

Wenn dieser Server Ihr Konto, Ihre Adresse oder Ihre Bestellhistorie speichert, nun ja, dann gehören die auch ihnen. Der Webhosting-Anbieter GoDaddy warnte, die Schwachstellen könnten Angreifern ermöglichen, Daten zu stehlen, Websites zu verunstalten oder Server vollständig zu übernehmen.

„Eine solche Schwachstelle könnte es einem Angreifer ermöglichen, seinen eigenen Code über das Internet auf einem betroffenen Server auszuführen, was zu gestohlenen Daten, einer verunstalteten Website oder einer vollständigen Übernahme führen kann“, sagt GoDaddy.

Was PHP angekündigt hat

Die PHP Foundation, die gemeinnützige Organisation, die die Entwicklung der Sprache finanziert, schlug am Dienstag Alarm. In einer auf X geteilten Erklärung hieß es: „Das PHP-Sicherheitsteam gibt eine Vorabankündigung: Bevorstehendes Sicherheitsrelease am Mittwoch, den 21. Oktober 2026, 14:00 UTC, zwei kritische Schwachstellen, beide mit CVSSv4 9.2 bewertet. PHP-Nutzern wird empfohlen, sich auf ein Update vorzubereiten. Frühere Veröffentlichung, falls Details öffentlich werden oder Hinweise auf aktive Ausnutzung vorliegen.“

Diese 9.2 stammt aus dem CVSS, dem Common Vulnerability Scoring System, das bewertet, wie gefährlich ein Fehler ist, basierend auf Dingen wie der Leichtigkeit, mit der er über das Internet erreichbar ist, und dem Schaden, den er anrichten kann. Es reicht von 0 bis 10, und alles ab 9,0 wird als kritisch eingestuft – diese beiden sind also so schlimm, wie es nur geht, ohne eine perfekte 10 zu erreichen.

Der Fix kam am Mittwoch um etwa 13:35 UTC, ein paar Minuten früher, als PHP-Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Die Sicherheitsempfehlung bemühte sich nicht um Subtilität: „Allen PHP-Nutzern wird dringend empfohlen, sofort zu aktualisieren.“

Aber einen Fix zu veröffentlichen und dafür zu sorgen, dass alle die Lösung umsetzen, sind nicht dasselbe, daher ist Vorsicht geboten.

Wie die Bugs funktionieren

Der erste Bug, CVE-2026-109618, tritt auf, wenn PHP mitten in der Bearbeitung einer Anfrage der Speicher ausgeht und diese halbfertigen Daten später so behandelt, als wären sie vollständig. Der zweite, CVE-2026-109619, lässt Überreste der Anfrage eines Besuchers im Speicher zurück, nachdem sie hätten verworfen werden sollen, wo die nächste Anfrage über sie stolpern kann.

Stellen Sie sich einen Koch vor, der weiterhin Bestellungen von Tickets liest, die bereits im Müll liegen. Schummeln Sie ein gefälschtes Ticket in den Mülleimer, und der Koch bereitet zu, was auch immer Sie darauf geschrieben haben. In diesem Fall ist die „Bestellung“ der Code des Angreifers, und der Server führt ihn aus.

PHP erklärte, das Risiko sei auf Servern mit einer gängigen Apache-Konfiguration namens mod_php am höchsten, wo ein demonstrierter Exploit „bevor irgendein Anwendungscode ausgeführt wird“ funktioniert. Mit anderen Worten: Die eigenen Abwehrmaßnahmen der Website, wie Anmeldebildschirme und WordPress-Sicherheits-Plugins, werden nicht einmal wach.

Forscher der PHP Foundation verwiesen auf PHPs Upload-Progress-Funktion, die verfolgt, wie viel einer Datei Sie gesendet haben, als einen der bestätigten Wege hinein. Sie ist seit mehr als einem Jahrzehnt standardmäßig aktiviert, und nur wenige Websites nutzen sie tatsächlich.

Ein Leck, dann Angriffe

Nichts davon sollte eigentlich schon öffentlich sein. Am Dienstag schrieb jemand im Hacker-News-Forum, dass zwei PHP-Schwachstellen an diesem Donnerstag offengelegt würden, und gab dabei zu, „keine Beweise außer ‚Quelle: vertrau mir, Bruder‘“ zu haben.

Es stellte sich heraus, dass der Bruder recht hatte. Die Sicherheitsfirma watchTowr bestätigte, dass die Bugs echt und unter Embargo waren – einer Vereinbarung, Details bis zur Fertigstellung eines Fixes geheim zu halten – und PHP zog seine Veröffentlichung um einen Tag vor.

„Wir sehen erste Angriffe aufkommen und aktualisieren die Gegenmaßnahmen, sobald neue Vektoren auftauchen“, schrieb Cloudflare-CTO Dane Knecht auf X am frühen Mittwochmorgen, fast sechs Stunden bevor der Patch ausgeliefert wurde. Cloudflare verteilte Notfall-Firewall-Regeln, Filter, die bekannte Angriffsmuster blockieren, an alle Kunden, aber Knecht nannte sie „nur eine Überbrückungslösung“.

Regierungen legen den Schalter um

Finnlands staatliches IT-Zentrum Valtori begann, öffentliche Webdienste vorsorglich offline zu nehmen, wie der öffentlich-rechtliche Sender Yle berichtete, während die niederländische nationale Cybersicherheitsbehörde ihre eigene Website abschaltete.

Das französische Innenministerium teilte mit, die Websites der Präfekturen seien „vorübergehend offline genommen worden, bis das Sicherheitsupdate durch den Herausgeber des Frameworks veröffentlicht wird“.

CERT-EU, das Cyber-Notfallteam der EU, riet Organisationen, die keinen Patch einspielen konnten, „in Erwägung zu ziehen, internetzugewandte Anwendungen von öffentlichen Netzen zu isolieren, bis ein Fix verfügbar ist“. Das ist Behördendeutsch für „ziehen Sie den Stecker“. Behörden in Australien, Japan und dem Vereinigten Königreich sagten laut Reuters im Wesentlichen dasselbe.

Was die viralen Posts falsch machten

Virale Threads auf X behaupteten, PHP-Versionen „bis zurück ins Jahr 2004“ seien anfällig. Das geht auf frühe Schätzungen zurück, wonach alles seit PHP 5 betroffen sei, was CERT-EU einräumte, sich auf Social-Media-Posts stützt.

Das E-Commerce-Sicherheitsunternehmen Sansec gibt den Bereich mit PHP 5.4 und später an. Also 2012, nicht 2004 – immer noch reichlich alt.

PHP liefert offizielle Releases nur für Versionen 8.2 und neuer, was die Behauptung „kein Fix für alte Versionen“ halb richtig macht. Angesichts der Schwere dieses Falls veröffentlichte sein Sicherheitsteam auch rudimentäre Quellcode-Patches für 7.4, 8.0 und 8.1, und Linux-Distributionen portieren eigene Fixes zurück.

Das Sicherheitsunternehmen Mallory zählte am 20. Oktober etwa 884.000 internetzugewandte Hosts, die PHP 8.1 oder älter angeben, also 59 % der rund 1,5 Millionen, die öffentlich eine Version anzeigen. Ein einzelner Shared-Hosting-Server kann viele Websites beherbergen, daher ist die Zahl der dahinterstehenden Seiten höher.

Einige Threads zählten auch Node.js dazu, eine andere Webtechnologie, die zufällig am selben Tag ihr eigenes, unabhängiges Sicherheitsupdate angesetzt hatte. Schlechtes Timing.

Selbst gepatchte Versionen werden nicht jeden Server auf einmal erreichen. „Wenn Sie sich auf das von Freiwilligen gepflegte https://rpms.remirepo.net verlassen, dringen wir darauf, jetzt auf Distributionspakete umzusteigen oder aus dem Quellcode zu bauen, damit Sie Updates sofort anwenden können. Das Repo wird heute keine Updates haben“, erklärte die PHP Foundation in ihrer Stellungnahme und bezog sich dabei auf eine beliebte, von Freiwilligen betriebene Quelle für PHP-Pakete für Linux-Server im Red-Hat-Stil.

Sollten Sie sich wirklich darum kümmern?

Sie sollten nicht in Panik geraten, es aber auch nicht mit einem Schulterzucken abtun. Eine gehackte Website zum Beispiel muss keine Blockchain berühren, um Ihre Wallet zu leeren. Im Jahr 2024 leiteten Angreifer die Frontends der DeFi-Protokolle Compound und Celer auf Seiten um, die verbundene Wallets leerten, und Curve Finance erlitt 2025 einen ähnlichen Angriff.

Das waren DNS-Hijacks, keine PHP-Bugs, aber der Trick ist derselbe: Die Seite sieht richtig aus, die URL sieht richtig aus, und der „Genehmigen“-Button schickt Ihre Token woandershin. Ein kompromittierter Server kann genau diese Art von Seite ausliefern.

Hacker können sehr kreativ und sehr schnell werden, wenn es um Zero-Day-Exploits geht.

Solche Bugs werden auch immer leichter zu finden, da Frontier-KI-Modelle zunehmend eingesetzt werden, um Software-Schwachstellen zu finden, und Experten sagten Decrypt im Juni, dass noch viel mehr Schwachstellen auftauchen könnten, je weiter sich diese Tools verbreiten.

Was als Nächstes passiert und was zu tun ist

Sobald ein Patch öffentlich ist, können Angreifer den alten und den neuen Code vergleichen, um genau zu sehen, was behoben wurde, und das Forensik-Team des Cybersicherheitsunternehmens Sansec sagte, es erwarte „Massenangriffe, die innerhalb von 15 Minuten nach der Veröffentlichung beginnen“. Als im Juni 2024 eine andere PHP-Schwachstelle öffentlich wurde, verzeichnete Akamai Exploit-Versuche gegen seine Köderserver innerhalb von 24 Stunden.

Sollte der Durchschnittsmensch also in Panik geraten? Nicht unbedingt. Dein Telefon, dein Browser und dein Laptop brauchen keinen PHP-Patch; die Arbeit liegt bei demjenigen, der die Websites betreibt, die du nutzt.

Wenn du eine Website betreibst, frage deinen Hosting-Anbieter, ob PHP aktualisiert wurde, und verlass dich nicht darauf, dass WordPress das für dich erledigt: Wordfence warnte, dass automatische Updates diesen Fix nicht anwenden werden, und riet Website-Betreibern herauszufinden, wer für die Aktualisierung von PHP auf ihren Servern verantwortlich ist. Wer 8.1 oder älter verwendet, muss ein Upgrade planen.

„Das Einzige, was ich sagen kann, ist, dass die einzige Abhilfe das Patchen / Aktualisieren von PHP ist“, sagte PHP-Kernentwicklerin Gina Peter Banyard auf Mastodon. „Ich weiß leider zu viel.“

Und wenn du PHP 8.2 verwendest, ist der Fix, den du gerade erhalten hast, einer deiner letzten: Diese Version erreicht am 31. Dezember 2026 das Ende ihrer Lebensdauer, danach erhält sie keine Sicherheitspatches mehr.