PHP hat am 21. Oktober die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht, um CVE-2026-109618 und CVE-2026-109619 zu beheben – zwei Schwachstellen mit einer Bewertung von 9,2 von 10, die eine nicht authentifizierte Remote-Code-Ausführung ermöglichen.

Die Schwachstellen veranlassten Finnland, die Niederlande und Frankreich, Regierungswebsites vorsorglich offline zu nehmen, nachdem Details vorzeitig bekannt geworden waren. Cloudflare meldete zudem Angriffe mehrere Stunden vor der Veröffentlichung des Patches. Die US-amerikanische National Security Agency empfahl Organisationen, die PHP einsetzen, ihre Websites abzuschalten, während Behörden in Australien, Japan und dem Vereinigten Königreich ähnliche Hinweise gaben.

Die meisten Internetnutzer müssen nichts installieren. Die Verantwortung für die Anwendung des Fixes liegt bei Website-Betreibern, Hosting-Unternehmen und Organisationen, die PHP-Server betreiben. Für PHP 8.1 und älter erscheinen keine regulären offiziellen Versionen mehr, wobei das PHP-Sicherheitsteam angesichts des Schweregrads eingeschränkte Quellcode-Patches für einige ältere Versionen veröffentlicht hat.

PHP betreibt laut W3Techs rund 70 % der Websites, deren serverseitige Sprache bekannt ist. Die Programmiersprache läuft auf Servern, wo sie Websites speichert und die von Besuchern angeforderten Seiten erzeugt. WordPress-Seiten basieren beispielsweise in der Regel auf PHP-Servern, so das WordPress-Sicherheitsunternehmen Wordfence.

Die beiden Fehler können einem Angreifer ermöglichen, Befehle auf einem PHP-Server auszuführen, ohne sich anzumelden. Diese Art von Schwachstelle wird als nicht authentifizierte Remote-Code-Ausführung bezeichnet. Je nach Server und den gespeicherten Daten könnte ein erfolgreicher Angriff Kontoinformationen, Adressen, Bestellhistorien oder andere vertrauliche Daten offenlegen.

Der Webhoster GoDaddy warnte, dass die Schwachstellen Angreifern das Stehlen von Daten, die Verunstaltung von Websites oder die vollständige Übernahme betroffener Server ermöglichen könnten.

„Eine Schwachstelle dieser Art könnte 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“, erklärte GoDaddy in seinem Sicherheitsupdate.

PHPs Sicherheitsankündigung

Die PHP Foundation, die gemeinnützige Organisation, die die Entwicklung der Sprache finanziert, gab am 20. Oktober eine Vorwarnung heraus. In einer auf X geteilten Erklärung hieß es:

„The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSSv4 9.2. PHP users are encouraged to prepare to update. Earlier release if details become public or active exploit evidence.“

The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSSv4 9.2. PHP users are encouraged to prepare to update. Earlier release if details become public or active exploit evidence. — The PHP Foundation (@ThePHPF) October 20, 2026

Das Common Vulnerability Scoring System (CVSS) bewertet Schwachstellen von 0 bis 10 anhand von Faktoren wie der Leichtigkeit der Ausnutzung über das Internet und dem potenziellen Schaden. Bewertungen ab 9,0 gelten als kritisch.

PHP veröffentlichte den Fix am 21. Oktober gegen 13:35 UTC, etwa 25 Minuten vor der angekündigten Zeit. In der Sicherheitsadvisory hieß es: „All PHP users are strongly encouraged to update immediately.“ Die Veröffentlichung wurde um einen Tag vorgezogen, nachdem Informationen über die Schwachstellen öffentlich kursierten und Anzeichen von Angriffen auftraten.

Wie die Schwachstellen funktionieren

CVE-2026-109618 tritt auf, wenn PHP bei der Verarbeitung einer Anfrage der Speicher ausgeht und teilweise aufgebaute Daten später als vollständig behandelt. CVE-2026-109619 ermöglicht es, dass Reste einer Besucheranfrage im Speicher verbleiben, nachdem sie eigentlich verworfen werden sollten, sodass eine nachfolgende Anfrage mit diesen Resten interagieren kann.

Das Risiko ist auf Servern mit mod_php am höchsten, einer verbreiteten Apache-Konfiguration. PHP teilte mit, dass ein demonstrierter Exploit „before any application code runs“ funktioniert, was bedeutet, dass Abwehrmaßnahmen der Website selbst – etwa Login-Bildschirme und WordPress-Sicherheits-Plugins – möglicherweise gar nicht erst zum Zug kommen.

Forscher der PHP Foundation identifizierten die Upload-Progress-Funktion von PHP als einen bestätigten Angriffsweg. Diese Funktion verfolgt den Fortschritt eines Datei-Uploads, ist seit über einem Jahrzehnt standardmäßig aktiviert und wird von vielen Websites nicht genutzt.

Weitere technische Informationen finden sich im PHP-Sicherheitsarchiv, in der watchTowr-Analyse und im NVD-Eintrag zu CVE-2026-109619. Die PHP-Dokumentation beschreibt zudem die relevante Session-Konfiguration.

Details vor dem Patch durchgestochen

Die Offenlegung war ursprünglich nicht vor der geplanten Veröffentlichung erwartet worden. Am Dienstag hatte ein Nutzer im Hacker-News-Forum geschrieben, dass zwei PHP-Schwachstellen am Donnerstag offengelegt würden, räumte jedoch ein, dass die Behauptung „no evidence beyond ‚source: trust me, bro.‘“ habe. Der Beitrag ist hier verfügbar.

Das Sicherheitsunternehmen watchTowr bestätigte später, dass die Schwachstellen real seien und einer Embargo-Vereinbarung unterlägen – einer Absprache, technische Details vertraulich zu halten, bis ein Fix bereitsteht. PHP beschleunigte daraufhin die Veröffentlichung.

Cloudflare-CTO Dane Knecht sagte am frühen Mittwochmorgen auf X, dass Angriffe bereits begonnen hätten, fast sechs Stunden vor Veröffentlichung des Patches. Cloudflare spielte Notfall-Firewall-Regeln für Webanwendungen an seine Kunden aus, einschließlich Kunden mit kostenlosen Tarifen, bezeichnete die Regeln laut Knecht jedoch nur als vorübergehende Maßnahme.

„PHP sites behind Cloudflare already have an initial set of WAF rules deployed for the known exploit vectors in these vulnerabilities. The rules are available to all customers, including free. We are seeing early attacks emerging and are updating mitigations as new vectors show… — Dane Knecht 🦭 (@dok2001) October 21, 2026“

Der Originalbeitrag ist außerdem über Dane Knechts X-Konto verfügbar.

Regierungen nehmen Websites offline

Finnlands staatliches IT-Zentrum Valtori begann, öffentliche Webdienste vorsorglich offline zu nehmen, wie der öffentlich-rechtliche Sender Yle berichtete. Die niederländische nationale Cybersecurity-Behörde nahm ebenfalls ihre Website vom Netz.

Das französische Innenministerium erklärte, die Websites der Präfekturen seien „temporarily taken offline pending the release of a security patch by the framework’s publisher“.

das EU-Cyber-Notfallteam CERT-EU empfahl Organisationen, die den Patch nicht einspielen konnten, zu „consider isolating internet-facing applications from public networks until a fix is available“.

Laut Reuters gaben Behörden in Australien, Japan und dem Vereinigten Königreich ähnliche Hinweise. Der Reuters-Bericht stellte ebenfalls fest, dass Websites möglicherweise offline genommen werden müssten, während die Betreiber die Fixes installierten.

Behauptungen zu betroffenen PHP-Versionen

Auf X kursierende Beiträge behaupteten, PHP-Versionen „bis zurück zu 2004“ seien betroffen. Diese Behauptung stammte aus frühen Schätzungen, wonach alle Versionen seit PHP 5 betroffen seien – eine Einschätzung, die laut CERT-EU auf Social-Media-Beiträgen beruhte.

Das E-Commerce-Sicherheitsunternehmen Sansec schätzte, dass PHP 5.4 und später betroffen seien, was den Zeitraum bis 2012 statt 2004 zurückführen würde. PHP liefert offizielle aktuelle Versionen nur für 8.2 und neuer aus. Aufgrund des Schweregrads dieser Schwachstellen veröffentlichte das Sicherheitsteam jedoch auch grundlegende Quellcode-Patches für PHP 7.4, 8.0 und 8.1, während Linux-Distributionen unabhängig Backports der Fixes begannen.

Das Sicherheitsunternehmen Mallory zählte am 20. Oktober etwa 884.000 internetzugängliche Hosts, die PHP 8.1 oder älter anboten. Das entsprach 59 % der rund 1,5 Millionen öffentlich sichtbaren Hosts, die ihre PHP-Version angaben. Die Zahl der betroffenen Websites ist höher, da ein einzelner Shared-Hosting-Server viele Websites hosten kann. Mallorys Forschung ist hier verfügbar, die Analyse von Sansec hier.

Einige Online-Beiträge bezogen auch Node.js in die Diskussion ein. Node.js ist eine separate Webtechnologie, die zufällig am selben Tag ein eigenes, unabhängiges Sicherheitsupdate geplant hatte.

Die PHP Foundation warnte, dass gepatchte Versionen nicht überall gleichzeitig verfügbar werden würden. Sie erklärte: „If you rely on the volunteer maintained we urge you to move to distro packages or building from source now, so you can immediately apply updates. The repo will not have updates today“ – mit Bezug auf eine ehrenamtlich betriebene Quelle für PHP-Pakete für Red-Hat-ähnliche Linux-Server. Das Paket-Repository ist unter verfügbar.

Mögliche Auswirkungen auf Websites und digitale Vermögenswerte

Eine kompromittierte Website muss nicht direkt mit einer Blockchain interagieren, um die digitalen Vermögenswerte der Nutzer zu gefährden. Im Jahr 2024 leiteten Angreifer die Frontends der DeFi-Protokolle Compound und Celer auf Seiten um, die dazu dienten, verbundene Wallets zu leeren. Curve Finance erlitt 2025 einen ähnlichen Angriff. Bei diesen Vorfällen handelte es sich um DNS-Hijacking und nicht um PHP-Schwachstellen, doch für Besucher kann das Ergebnis ähnlich aussehen: Die Website und die URL wirken legitim, während eine Genehmigungsaktion Token anderswohin sendet.

Ein kompromittierter PHP-Server könnte genutzt werden, um eine solche betrügerische Seite auszuliefern. Der Zusammenhang zwischen angreifbarer Web-Infrastruktur und Kryptodiebstahl wurde auch vom Unternehmer @levelsio diskutiert, der auf X erklärte, er habe seine Websites und virtuellen privaten Server abgeschaltet, während er auf den Patch wartete.

„I pre-emptively disconnected ALL my sites / VPS servers from the web I'll wait for the patch to hit at 2 PM UTC If you have a PHP website, probably good to take them down until you patch PHP 69.3% of the web runs on PHP so this is going to be intense! Good time maybe to buy… — @levelsio (@levelsio) October 21, 2026“

Der Beitrag ist außerdem auf X verfügbar. Die früheren Decrypt-Berichte zum Vorfall mit Compound und Celer sowie zum Curve-Angriff sind hier und hier verfügbar.

Die Schwachstellen treten zudem auf, während KI-Modelle der Spitzenklasse zunehmend zur Auffindung von Softwarefehlern eingesetzt werden. Experten sagten Decrypt im Juni, dass sich mit der Verbreitung solcher Tools viele weitere Schwachstellen finden lassen könnten. Decrypts Bericht ist hier verfügbar.

Was Website-Betreiber tun sollten

Sobald ein Patch öffentlich ist, können Angreifer den verwundbaren und den gepatchten Code vergleichen, um festzustellen, was geändert wurde. Das Forensik-Team von Sansec sagte voraus, es erwarte „mass attacks to start within 15 minutes of the release“. Als im Juni 2024 eine andere PHP-Schwachstelle offengelegt wurde, verzeichnete Akamai innerhalb von 24 Stunden Exploit-Versuche gegen seine Köderserver. Akamais Analyse ist hier verfügbar.

Telefone, Browser und private Laptops benötigen kein PHP-Update. Die Arbeit obliegt den Organisationen, die Websites und Server betreiben. Website-Besitzer sollten ihre Hosting-Provider fragen, ob PHP aktualisiert wurde, und herausfinden, wer für die Wartung des Servers verantwortlich ist.

Wordfence warnte, dass automatische WordPress-Updates diesen Fix nicht einspielen würden. Website-Betreiber müssen daher bestätigen, dass PHP selbst gepatcht wurde, statt davon auszugehen, dass ein WordPress-Update das Problem behebt.

Der PHP-Core-Entwickler Gina Peter Banyard sagte auf Mastodon: „The only thing I can say is that the only mitigation is patching / upgrading PHP“ und fügte hinzu: „I sadly know too much.“ Der Beitrag ist hier verfügbar.

Organisationen, die PHP 8.1 oder älter betreiben, müssen ein Upgrade planen, da diese Versionen keine regulären offiziellen Versionen mehr erhalten. Auch Nutzer von PHP 8.2 sehen einer nahenden Frist entgegen: PHP 8.2 erreicht am 31. Dezember 2026 das Ende seiner Lebensdauer und erhält danach keine Sicherheitspatches mehr.