Ein Update ist nötig. Eine automatische Entwarnung ist es nicht. Zwei kritische Fehler in PHP können Websites und Webdienste gefährden. Im ZDFheute-live-Interview vom 22. Oktober erklärt IT-Sicherheitsforscher Dennis-Kenji Kipker die Tragweite. Die Warnung ist begründet. An einigen Stellen braucht sie aber wichtige Grenzen: Ein verwundbarer Server ist kein nachgewiesen gehackter Server; fremder Programmcode bedeutet nicht automatisch Zugriff auf jedes Benutzerkonto. Und eine geschlossene Lücke entfernt keine zuvor hinterlegte Schadsoftware.
Stand: 22. Oktober 2026. Wir prüfen das vollständige Gespräch von 12: 09 Minuten, einschließlich der Fragen, der Verantwortung für PHP und der Aussagen über künstliche Intelligenz. Vorhersagen über das Ende der Gefahr sind keine festgestellten Ergebnisse. Die nachfolgenden Belege beziehen sich auf veröffentlichte Hersteller-, Forschungs- und Behördenhinweise, nicht auf einen Sicherheitstest einzelner Websites.
Wie groß ist die Gefahr wirklich?
Im Kern richtig, als Rangliste nicht überprüfbar. Kipker bewertet den Vorfall als außergewöhnlich und vergleicht die Größenordnung mit Ereignissen, die nur alle fünf bis zehn Jahre auftreten. Dafür nennt das Gespräch keine definierte Vergleichsreihe. Diese zeitliche Einordnung bleibt seine fachliche Bewertung. Dass eine verbreitete Servertechnik betroffen ist, belegt dagegen auch die gemeinsame Warnung europäischer Sicherheitsbehörden.
Die Einleitung spricht von Hunderten Millionen betroffenen Websites. Eine solche absolute Zahl lässt sich mit dem im Gespräch genannten Marktanteil allein nicht nachweisen. Dazu bräuchte man eine belastbare Grundgesamtheit und den konkreten verwundbaren beziehungsweise bereits aktualisierten Bestand. Potenzielle Reichweite, angegriffene Systeme und erfolgreiche Einbrüche sind drei unterschiedliche Größen.
Die 70 Prozent haben einen Nenner
W3Techs weist am 22. Oktober 69,3 Prozent aus – unter Websites, deren serverseitige Programmiersprache der Dienst bestimmen kann. Das passt ungefähr zu Kipkers ausdrücklich eingeschränkter 70-Prozent-Angabe. Es bedeutet weder 70 Prozent aller Geräte noch 70 Prozent erfolgreich kompromittierte Websites. Auch die technischen Erkennungsgrenzen der Erhebung verschwinden durch die große Zahl nicht.
Was die beiden Fehler ermöglichen
Richtig: Es geht um zwei Fehler der PHP-Laufzeit, nicht um ein bestimmtes Website-Plugin. Die offiziellen Meldungen zu CVE-2026-109618 und CVE-2026-109619 beschreiben unsichere Speicherzustände bei der Verarbeitung von Webanfragen. Ein nicht angemeldeter Angreifer kann unter den beschriebenen Bedingungen fremden Code ausführen. Die vereinfachte Erklärung, ein Server halte Schadcode für einen normalen Befehl, vermittelt die Wirkung, beschreibt den Speicherfehler aber nicht präzise.
Zum betroffenen Einsatzbereich zählen unter anderem PHP-FPM, Apache mit mod_php und weitere Webanfrage-Handler. Welche Ausnutzung funktioniert, hängt auch von Betriebsart und Anwendung ab. Eine beliebige einzelne Anfrage garantiert deshalb keinen erfolgreichen Einbruch auf jedem PHP-Server. Die Dringlichkeit des Updates bleibt bestehen.
Volle Kontrolle über sämtliche Daten? So pauschal nicht
Kontext fehlt.CERT.at grenzt die Rechte ausdrücklich ein: Ausgeführter Code besitzt die Rechte des Kontos, unter dem der Webserver- oder PHP-Prozess läuft. Das kann ausreichen, um Anwendungsdateien zu verändern, erreichbare Datenbanken auszulesen oder weitere Schadsoftware abzulegen. Es ist aber nicht automatisch die höchste Systemberechtigung und nicht zwangsläufig Zugriff auf jede Datei anderer Konten.
Die von Kipker genannten Schäden an Shopdaten und manipulierten Eingaben sind damit plausible Folgen eines erfolgreichen Angriffs. Sie sind im Interview keine Belege für konkrete gestohlene Kreditkarten bei einer bestimmten Firma. Auch eine mobile App kann betroffen sein, wenn ihr Serverdienst verwundbares PHP nutzt; die App-Oberfläche allein verrät das nicht.
Schon lange bekannt – aber was genau?
Die Vorgeschichte ist belegt, die verkürzte Darstellung braucht eine zeitliche Trennung. Nach der Chronologie der PHP Foundation wurden bereits 2024 verdächtige Speicherprobleme erkannt. Damals waren konkrete Angriffswege nach dieser Darstellung noch nicht nachgewiesen; die Arbeit stockte. Einen bestätigten Bericht über Codeausführung datiert die Foundation auf den 11. August 2026. Sie räumt organisatorisches Versagen bei der früheren Bearbeitung ein.
Das entkräftet die Kritik an einer verspäteten Behandlung nicht. Es rechtfertigt aber auch nicht die weitergehende Behauptung, ein bereits vollständig demonstrierter Angriff sei seit Jahren unverändert bekannt und bewusst ignoriert worden. Die Chronologie stammt von einer beteiligten Organisation und ersetzt keine unabhängige Aufarbeitung.
Die Veröffentlichungsprobleme sind dokumentiert
Die Kritik an der kurzen Reaktionszeit hat einen nachvollziehbaren Kern: Die Foundation beschreibt vorzeitige Informationen und ein veröffentlichtes Demonstrationsvideo am 20. Oktober. Der geplante Veröffentlichungstag wurde vorgezogen. ENISA nennt den 21. Oktober um 13:40 UTC als tatsächlichen Updatezeitpunkt – 15:40 Uhr in Deutschland. Eine geplante Uhrzeit und die tatsächliche Freigabe sollten nicht vermischt werden.
Dass Betreiber dringend handeln müssen, heißt allerdings nicht, dass zuvor keinerlei Vorbereitung stattfand. Cloudflare berichtet über vorbereitete Schutzregeln und deren Aktivierung für seine WAF-Nutzer vor der öffentlichen Freigabe. Das ist eine zusätzliche Schutzschicht für diese Kunden, keine allgemeine Garantie für das Internet.
Die Foundation hat PHP nicht erfunden
Falsch ist die historische Begründung, die Foundation habe die Sprache herausgebracht. Laut offizieller PHP-Geschichte entstanden die ersten PHP-Werkzeuge 1994 durch Rasmus Lerdorf; 1995 wurde der Quellcode öffentlich. Die heutige Foundation beschreibt ihre Aufgabe als Unterstützung und Finanzierung von Entwicklern. Sie ist nicht mit dem Ursprung der Sprache gleichzusetzen.
Welche Beteiligten welche Verantwortung tragen, ist damit nicht abschließend entschieden. Entwickler, Projektorganisation, Distributoren und Betreiber haben unterschiedliche Aufgaben. Die sachlich sinnvolle Forderung des Interviews bleibt: Unternehmen müssen wissen, welche Komponenten sie tatsächlich betreiben, und Sicherheitsmeldungen an die verantwortlichen Stellen bringen.
Angriffe sind belegt – eine globale Millionenzahl nicht
AWS berichtet aus seinen MadPot-Sensoren über einen Ausnutzungsversuch bereits am 17. Oktober und weitere Aktivitäten vor sowie nach der öffentlichen Bekanntmachung. Zugleich begrenzt AWS selbst, was ein Versuch an einem Sensor über seinen Erfolg auf realen Systemen aussagt. Cloudflare meldet ebenfalls Angriffsverkehr und veränderte Angriffsmuster.
Damit wäre es falsch, die Gefahr als bloß theoretisch abzutun. Die Frage des Moderators nach möglicherweise Millionen Angriffen ist aber keine nachgewiesene Gesamtzahl. Aus den geprüften Berichten folgt weder eine weltweit bestätigte Zahl erfolgreicher Einbrüche noch, dass jeder dieser Angriffe von einer KI gesteuert wurde. Mehrere mögliche Motive und Akteure sind plausibel; ein einheitliches, bewiesenes Täterprofil nennt auch Kipker nicht.
Welche Updates schließen die Lücken?
Seit 21. Oktober sind die offiziellen korrigierten PHP-Versionen verfügbar:
| Versionszweig | Korrigierte Upstream-Version |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
Die Versionsnummer allein genügt bei Anbieterpaketen nicht. Ein Distributor kann die Korrektur in eine ältere Paketversion zurückportieren. Ubuntu dokumentiert solche aktualisierten Pakete konkret. Umgekehrt ist die Auswahl „PHP 8.5“ im Hostingmenü noch kein Nachweis für den tatsächlich laufenden Patchstand.
Für PHP 8.1 und ältere Zweige gibt es keine regulären neuen Upstream-Sicherheitsreleases mehr; Anbieter können eigene Rückportierungen liefern. PHP 8.2 erreicht laut Projekt am 31. Dezember 2026 das Supportende. Ein langfristig unterstützter Betrieb und die aktuelle Notfallkorrektur sind daher getrennt zu planen.
Ein Patch ist keine rückwirkende Bereinigung
Diese Unterscheidung ist für Betreiber entscheidend. Das Update korrigiert die verwundbare Software. Wenn vorher bereits Schadcode abgelegt oder ein Zugang gestohlen wurde, entfernt der Versionswechsel das nicht automatisch. Aus den von AWS dokumentierten früheren Versuchen folgt als Vorsichtsmaßnahme: Auch Vorgänge vor dem öffentlichen Veröffentlichungstag gehören in eine Prüfung möglicher Vorfälle.
Das bedeutet keine pauschale Behauptung, jeder Server sei schon kompromittiert. Es bedeutet, Aktualisierung und Untersuchung eines begründeten Verdachts getrennt zu behandeln. Auch Cloudflare fordert Updates trotz seiner Schutzregeln. Die Behörden empfehlen die Abstimmung mit Hosting- und Diensteanbietern und priorisieren öffentlich erreichbare Systeme. Zeitweise Abschaltung kann eine Schutzentscheidung sein; sie beweist für sich keinen Datenabfluss.
Bis Ende der Woche erledigt?
Offene Prognose. Kipker formuliert selbst eine Hoffnung: Das Gröbste könnte rasch behoben sein, die Nacharbeit aber Wochen oder Monate dauern. Am 22. Oktober gibt es in den geprüften Quellen keine vollständige Erhebung, wie viele Websites weltweit bereits aktualisiert sind. Daher lässt sich weder diese Frist noch die später im Gespräch vermutete große Mehrheit schon aktualisierter Alltagsseiten bestätigen.
Die Größe eines Anbieters ist ebenfalls keine technische Zertifizierung seines Patchstands. Wer einen konkreten Dienst einschätzen muss, braucht dessen belastbare Mitteilung oder den Nachweis des verantwortlichen Betreibers.
Was das für Besucher und private Betreiber heißt
Die unmittelbare Lücke liegt in einer PHP-Serverlaufzeit, nicht im Namen einer Website und nicht automatisch im Browser der Besucherin. Man muss daraus keine allgemeine Internetsperre für Privatpersonen ableiten. Eine manipulierte Website kann trotzdem gefährliche Inhalte oder Eingaben abgreifen. Konkrete Warnungen betroffener Dienste sollten ernst genommen werden.
Beim im Gespräch genannten eigenen NAS zählt die tatsächlich installierte und nach außen erreichbare Software. Nicht jedes NAS und nicht jeder Saugroboter wird allein durch diese Meldung verwundbar. Wer selbst PHP-Webdienste betreibt, ist dagegen ebenfalls Betreiber und sollte die Anbieterhinweise prüfen. Die empfohlenen Passwortwechsel sind bei einem bestätigten oder begründeten Datenleck sinnvoll; aus dieser Meldung allein folgt kein Beleg, dass sämtliche Internetpasswörter gestohlen wurden.
KI hilft bei der Suche – die Zuschreibung von Angriffen bleibt eine andere Frage
Der belegte Verteidigungsbeitrag ist konkreter als eine pauschale Angriffserzählung.OpenAI beschreibt die Entdeckung durch Calif mit KI-Unterstützung und die Zusammenarbeit mit PHP-Verantwortlichen sowie weiteren Forschern. Das ist ein veröffentlichter Bericht eines Beteiligten, kein unabhängiger Nachweis jedes dort bewerteten Erfolgs. Die PHP-Chronologie nennt mehrere voneinander unabhängige Meldungen.
Dass dieselben Werkzeuge auch Angreifern helfen können, ist die nachvollziehbare Dual-Use-Einordnung des Interviews. Sie ersetzt aber keine Untersuchung, welche konkreten beobachteten Angriffe hier tatsächlich KI-gesteuert waren. Ob der Vorfall einen historischen Wendepunkt markiert, ist eine Bewertung. Die überprüfbare Aufgabe bleibt greifbarer: Fehler korrigieren, laufende Pakete prüfen und bekannte Vorfälle untersuchen.
Fazit: Die zentrale Warnung des ZDF-Gesprächs stimmt: Die PHP-Lücken erfordern rasches Handeln. Unpräzise sind die automatische Gleichsetzung von Codeausführung mit uneingeschränkter Serverkontrolle und die Herkunft der PHP Foundation. Marktanteile, Angriffszahlen und zeitliche Hoffnungen benötigen klare Grenzen. Für den Alltag ist die nützlichste Trennung: verwundbar, angegriffen und erfolgreich kompromittiert bedeuten nicht dasselbe.