DEEN

Notiz · 21. Oktober 2026

[de]55/26Design

Die KI hat die Lücke gefunden. Was das für alte Websites heißt.

Nummer
J55 / 55/26
Sparte
Design
Datum
21. Oktober 2026

Der älteste betroffene Code ist über zehn Jahre alt, und gefunden wurde der Fehler mit Werkzeugen, die es so noch nicht lange gibt. Ich arbeite jeden Tag mit genau solchen Werkzeugen. Deshalb lese ich diese Nachricht anders als die meisten.

Wer die Lücke gefunden hat

Hinter PHP2Shell stehen zwei Fehler in PHP, die am 21. Oktober 2026 geschlossen wurden. Wie sie gefunden wurden, hat das Team von Calif noch am selben Tag aufgeschrieben: entdeckt von Calif, OpenAI und Wiz, unter anderem mit KI-gestützten Prüfwerkzeugen, die den Code nach bestimmten Mustern durchsucht haben. Das Audit begann am 30. Juli, der erste Fehler ging am 11. August an das PHP-Team. Der älteste betroffene Codepfad stammt aus PHP 5.4.0, einer Version von 2012.

Man muss das einen Moment wirken lassen. Ein Fehler, dessen älteste Spur über zehn Jahre zurückreicht, steht in einem Programm, das auf einem großen Teil aller Webserver läuft, wird von unzähligen Entwicklern benutzt, gelesen und erweitert, und fällt erst auf, als jemand mit neuen Werkzeugen gezielt danach sucht. Dass er dann innerhalb von Wochen gefunden war, ist eigentlich die gute Nachricht. Die weniger gute steht gleich daneben: Solche Werkzeuge gibt es nicht nur bei den Guten.

Zweimal in gut drei Monaten

Im Juli hatte es schon WordPress selbst getroffen. Am 17. Juli 2026 kam ein Update für zwei Lücken in WordPress, die zusammen eine Codeausführung ohne Anmeldung erlaubten. Das BSI nennt sie wp2shell, stufte sie ebenfalls mit Orange ein und schrieb in seiner Warnung vom 20. Juli von Berichten über erste Ausnutzungen. Bemerkenswert ist ein Satz darin: Auch diese Lücke wurde laut dem Unternehmen, das sie veröffentlicht hat, mit Hilfe eines KI-Modells gefunden. Damals lag der Fehler in WordPress, und ein WordPress-Update hat ihn behoben. Diesmal liegt er im Fundament darunter, und das Dashboard kann nichts dagegen tun. Wer eine WordPress-Seite betreibt, hatte also binnen gut drei Monaten zweimal einen Grund, nachts an seinen Server zu denken.

Das ist keine Schwäche von WordPress oder PHP im Besonderen. Es ist die Eigenschaft jeder Website, auf deren Server ein Programm läuft, das Anfragen von außen verarbeitet. Je mehr Code dort läuft und je älter er ist, desto mehr gibt es zu finden. Bisher war das ein überschaubares Risiko, weil Finden Zeit kostete. Genau diese Zeit wird gerade kürzer.

Warum ich die Nachricht anders lese

Ich baue seit einiger Zeit selbst mit KI, Werkzeuge für mein Studio und Websites für Kunden. Ich beschreibe, was ich brauche, die KI macht einen Vorschlag, und ich prüfe ihn, bevor irgendetwas online geht. Aus dieser Arbeit weiß ich, wie gründlich diese Werkzeuge Code lesen können, und auch, wie schnell. Wenn ich mir vorstelle, dass jemand dieselbe Gründlichkeit auf die alten Plugins einer Praxis-Website richtet, die seit 2019 niemand mehr angefasst hat, wird mir nicht angst, aber sehr klar.

Die naheliegende Reaktion wäre, die KI für das Problem zu halten. Ich halte sie eher für den Boten. Das Problem ist die Bauweise: viele Schichten Code, die öffentlich erreichbar sind und von verschiedenen Leuten in verschiedenem Tempo gepflegt werden. Daran ändert auch das beste Update nichts, es verschiebt die Frage nur bis zur nächsten Meldung.

Was ich daraus mache

Ich baue Websites deshalb mit Kenala so, dass auf dem Server möglichst wenig zu finden ist. Die Seiten werden vorher fertig gebaut und liegen als Dateien im Netz, ausgeliefert über Cloudflare, ohne PHP, ohne Datenbank, ohne Plugins. Die KI hilft beim Bauen, nicht beim Betrieb: Was öffentlich erreichbar ist, sind fertige Seiten, kein Programm, das Anfragen verarbeitet. Und jede Änderung sieht ein Mensch, bevor sie online geht. Du sagst, was sich ändern soll, siehst die Vorschau und gibst frei.

Unverwundbar ist damit nichts, das wäre ein Versprechen, das niemand halten kann. Aber eine Lücke wie PHP2Shell findet dort nichts, wo sie ansetzen könnte. Und für eine Seite, die vor allem zeigen und informieren soll, ist das die ruhigere Grundlage für die nächsten Jahre, in denen solche Funde vermutlich häufiger werden.

Schon im Juli, vor beiden Ereignissen, habe ich aufgeschrieben, wann eine Website ohne WordPress sinnvoll ist und wann nicht. Was die aktuelle Lücke für Deine Seite heißt, steht in der Einordnung, wie Du sie prüfst, im Selbsttest. Wie eine Website mit Kenala entsteht, steht unter Websites mit Kenala und kurz auf kenala.de. Wenn Du Fragen hast, schreib mir, per Mail oder wie es Dir am liebsten ist.

Quellen

Calif, „php2shell: A tale of two PHP remote vulnerabilities“, calif.io, Oktober 2026. BSI, IT-Sicherheitshinweis BITS-H Nr. 2026-297981-1132, Version 1.1 vom 21. Oktober 2026. BSI, IT-Sicherheitshinweis „WordPress: Schwachstellen erlauben Remote Code Execution“, BITS-H Nr. 2026-271984-1132, Version 1.1 vom 20. Juli 2026. Gemeinsame Erklärung von EU-Kommission, ENISA, CERT-EU und Europol zu den kritischen PHP-Lücken, 21. Oktober 2026.

Alle Beiträge zu PHP2Shell→
Nächster Eintrag
J54
21.10.26 · Design
PHP-Sicherheits­lücke PHP2Shell: Ist meine Website betroffen? In fünf Minuten prüfen.
Fünf Fragen, fünf Minuten, kein Fachwissen nötig. Danach weißt Du, ob Deine Website betroffen sein kann, und Du weißt, wen Du fragen musst.
→