Am 21. Oktober hatten einige hunderttausend Menschen in Deutschland denselben Tag: Meldung lesen, Version prüfen, Update einspielen, Protokolle durchsehen, hoffen. Für die anderen war es ein Mittwoch.
Nach Angaben der Entdecker liefen rund 70 Prozent aller Websites auf der betroffenen Software. Diese Zahl ist seitdem überall zitiert worden, meistens falsch. Sie bedeutet nicht, dass 70 Prozent der Websites gehackt wurden. Sie bedeutet: Sie hätten es werden können, weil der verwundbare Code bei ihnen lief.
Bleibt die andere Seite der Rechnung. Was ist mit den übrigen 30 Prozent?
Erst einmal: Diese 30 Prozent sind kein Club
Damit hier kein falscher Eindruck entsteht, gleich zu Beginn die unbequeme Hälfte der Antwort.
Die Websites, die PHP2Shell nicht treffen konnte, laufen auf .NET, auf Java, auf Node.js, auf Python – oder auf gar nichts, weil sie vorab erzeugt und nur noch ausgeliefert werden. Was sie verbindet, ist nicht Sicherheit. Was sie verbindet, ist, dass sie bei dieser einen Lücke nicht im Weg standen.
Jede dieser Plattformen hat ihre eigenen schlechten Tage. Für .NET gab es sie, für Java gab es sie mit Ansage, und wer Node.js einsetzt, hat seinen Anteil an Abhängigkeiten, die nachts aktualisiert werden wollen. Erst vergangene Woche hat Node.js hochriskante Lücken geschlossen.
Die 30 Prozent sind also nicht sicherer. Sie waren an diesem Tag nur nicht dran.
Wer daraus „wechselt die Technologie und ihr habt Ruhe" macht, verkauft etwas. Trotzdem lohnt der Blick auf die Frage, warum manche Häuser an solchen Tagen weniger zu tun haben – denn das hat Gründe, und die haben wenig mit der Programmiersprache zu tun.
Die Frage, auf die es wirklich ankommt
Sie lautet nicht „welche Technologie", sondern: Wie viel Software läuft auf Ihrem Server, wenn ein Fremder eine Adresse aufruft?
Bei einer typischen WordPress-Installation ist die Antwort: ziemlich viel. Ein Programmkern, dazu zwischen zwölf und vierzig Erweiterungen, ein Theme, eine Datenbank, eine Laufzeitumgebung. Jeder einzelne Teil davon führt Code aus, sobald jemand die Seite besucht – und jeder Teil kann eine Lücke haben. Rechnen Sie einmal nach, wie viele Hersteller das sind. Bei den meisten Mittelstandsseiten kommen zwanzig und mehr zusammen, und jeder von ihnen kann Ihnen einen Dienstagabend verderben.
Bei einer vorab erzeugten Website ist die Antwort: nichts. Der Server reicht eine Datei heraus, die vor Tagen oder Wochen entstanden ist. Es gibt keinen Programmkern, der angesprochen wird, keine Datenbankabfrage, keine Erweiterung, die Eingaben verarbeitet.
Das ist kein Sicherheitsmerkmal im engeren Sinn. Es ist schlicht weniger Fläche. Und Fläche ist das, worauf Lücken landen.
Wie das bei uns aussieht – mit Zahlen
Wir schreiben diesen Beitrag nicht aus der Zuschauerperspektive, deshalb die eigenen Verhältnisse offengelegt.
Unsere eigene Website hat am 21. Oktober nichts gebraucht. Sie liefert vorab erzeugte Seiten aus; im Auslieferungsverzeichnis liegt keine einzige PHP-Datei, nur eine Konfigurationsdatei für den Webserver. Ein Aufruf von `/index.php`, `/wp-login.php` oder `/info.php` beantwortet unser Server mit 404 – nicht weil wir das gesperrt hätten, sondern weil es dort nichts gibt. Es wird kein Sitzungscookie gesetzt, weil es keine serverseitigen Sitzungen gibt.
Das war keine Entscheidung gegen PHP2Shell, die kannte im Frühjahr niemand. Es war eine Entscheidung für Geschwindigkeit, für weniger Wartung und dafür, nicht bei jedem Hersteller-Update nervös zu werden. Dass sie an diesem Mittwoch auch Sicherheit bedeutete, war ein Nebeneffekt.
Dasselbe gilt für die Kundenauftritte, die wir gebaut haben. Sie liefern ebenfalls vorab erzeugte Seiten aus – dieselbe Bauweise, aus denselben Gründen, und das seit Monaten, nicht seit vorletzter Woche. Für sie war der 21. Oktober genauso ein gewöhnlicher Mittwoch.
Eine Ausnahme gibt es: ein gewachsenes Redaktionssystem, das wir übernommen haben und weiter betreuen. Dort lief am 21. Oktober dasselbe Programm wie überall – prüfen, aktualisieren, Protokolle durchsehen. PHP steht dort heute auf 8.2.35, der Fassung mit den geschlossenen Lücken. Das gehört dazu, wenn man über Zahlen redet.
Der Preis, den die 30 Prozent zahlen
Weniger Fläche heißt auch weniger Möglichkeiten. Das gehört in denselben Absatz, sonst wird aus einer Beobachtung ein Verkaufsgespräch.
| Was wegfällt | Was stattdessen nötig ist |
|---|---|
| Kommentare, Foren, Benutzerkonten | Fremddienst einbinden oder darauf verzichten |
| Serverseitige Suche über große Bestände | Suchindex im Browser oder gehosteter Suchdienst |
| Echtzeitdaten, Lagerbestände, Preise | Schnittstelle, die im Browser nachlädt |
| Formulare mit komplexer Verarbeitung | Eigener kleiner Dienst dahinter |
| „Mal eben ein Plugin installieren" | Jede Funktion wird gebaut, nicht geklickt |
Für einen Onlineshop mit 4.000 Artikeln und Lagerabgleich ist eine vorab erzeugte Seite der falsche Weg. Wir sagen das auch Kunden, die uns danach fragen – nachzulesen in Statische Website: wo die Grenzen liegen und für Shops ausdrücklich in Warum ein Onlineshop nicht statisch wird.
Für eine Firmenwebsite mit 40 bis 200 Seiten, einem Kontaktformular und einem Journal sieht die Rechnung anders aus. Dort ist der Funktionsverlust gering und der Wegfall des Wartungsrisikos erheblich.
Was Sie davon haben, ohne irgendetwas umzustellen
Der nützlichste Teil dieses Beitrags ist nicht die Empfehlung, sondern die Frage, die Sie sich stellen können, egal worauf Ihre Seite läuft:
Wie viele Hersteller müssen gleichzeitig keinen Fehler machen, damit Ihre Website sicher bleibt?
Zählen Sie nach. Betriebssystem, Webserver, Laufzeitumgebung, Redaktionssystem, Theme, jede Erweiterung einzeln, Datenbank. Bei einer gewachsenen WordPress-Installation kommen Sie auf zwanzig bis fünfzig. Jede dieser Zahlen ist eine Wahrscheinlichkeit, und sie addieren sich.
Daraus folgen drei Dinge, die nichts kosten:
Erstens: Jede Erweiterung, die Sie nicht brauchen, gehört weg. Nicht deaktiviert – deaktivierte Erweiterungen liegen weiterhin im Dateisystem und können weiterhin angesprochen werden. Entfernt.
Zweitens: Wissen, was läuft. Eine Liste mit Version und Hersteller, die aktuell ist. Ohne sie können Sie am Tag der nächsten Meldung nicht einmal feststellen, ob Sie betroffen sind. Die meisten Häuser brauchen dafür Stunden, und diese Stunden sind genau die, in denen gescannt wird.
Drittens: Wissen, wer patcht. Sie, die Agentur oder der Hoster – und bis wann. Wenn Sie diese Frage nicht in einem Satz beantworten können, ist sie offen, und offen heißt im Zweifel: niemand. Was dann passiert, steht in Der Hoster hat nicht gepatcht.
Die ehrliche Bilanz dieses Mittwochs
Es wäre bequem, diesen Beitrag mit „deshalb statisch" zu beenden. Das wäre aber genau die Sorte Schlussfolgerung, vor der wir oben gewarnt haben.
Die redliche Fassung lautet: Dieser eine Vorfall hat sichtbar gemacht, was Angriffsfläche im Alltag bedeutet. Wer wenig davon hat, hatte an diesem Tag wenig zu tun. Beim nächsten Mal kann es anders herum sein – und irgendwann wird es das.
Was bleibt, ist kein Technologieversprechen, sondern eine nüchterne Frage nach dem Verhältnis: Wie viel laufende Software brauchen Sie wirklich für das, was Ihre Website tun soll? Alles darüber hinaus ist Fläche, die gepflegt werden will – von jemandem, der benannt ist, mit einer Frist, die eingehalten wird.
Checkliste: erste Schritte
- Zählen, wie viele Hersteller an Ihrer Website beteiligt sind
- Erweiterungen, die niemand braucht, entfernen statt deaktivieren
- Eine Liste mit Versionsständen anlegen, die am Tag der nächsten Meldung belastbar ist
- Schriftlich klären, wer patcht und innerhalb welcher Frist
- Prüfen, welche Funktionen Ihrer Seite wirklich serverseitig laufen müssen
- Testsysteme und alte Unterauftritte aufspüren – dort schaut niemand hin
- Bei der nächsten Meldung zuerst die Liste ziehen, nicht das Internet lesen
Wie DAVINCI unterstützt
Wir zählen mit Ihnen durch, wie viele bewegliche Teile Ihre Website hat, und sagen Ihnen, welche davon wirklich gebraucht werden – auch dann, wenn das Ergebnis lautet, dass Ihr bestehendes System bleiben kann. Eine erste Einschätzung von außen gibt der kostenlose PHP-Sicherheitscheck, die Sicht von innen das Prüfwerkzeug für den eigenen Server. Für den Blick eines Menschen auf Ihren konkreten Fall gibt es den Quick-Check. Wenn aus der Zählung ein Umstieg folgt, beschreibt WordPress ablösen das Vorgehen. Erreichbar sind wir über die Kontaktseite.
Häufige Fragen
Heißt das, PHP ist unsicher?
Nein. PHP ist ausgereift, wird aktiv gepflegt, und die Lücken wurden zügig geschlossen. Dass es 70 Prozent der Websites betrifft, liegt an der Verbreitung, nicht an der Qualität. Eine Lücke in einer so verbreiteten Grundlage ist ein Großereignis – das wäre sie bei jeder anderen genauso.
Sind statische Websites sicher?
Sicherer gegen diese Art von Angriff, ja – es gibt serverseitig nichts auszuführen. Gegen andere Wege nicht: Ein Angreifer, der Zugang zum Auslieferungsverzeichnis bekommt, kann dort ebenso Inhalte verändern. Und der Bereich, über den Sie die Seite pflegen, ist weiterhin ein Ziel.
Wir haben WordPress. Müssen wir jetzt wechseln?
Nicht deswegen. Ein gepflegtes WordPress mit wenigen Erweiterungen, zügigen Updates und einer benannten Zuständigkeit ist besser aufgestellt als eine schlecht betreute Seite auf irgendeiner anderen Grundlage. Ein Wechsel lohnt sich, wenn Sie den Pflegeaufwand nicht leisten können oder wollen – nicht als Reaktion auf eine einzelne Meldung.
Wie lange dauert eine Umstellung?
Für eine Firmenwebsite im üblichen Umfang rechnen wir mit 48 Stunden ab Freigabe und Zugang, mit unverändertem Inhalt und erhaltenen Adressen. Was dabei genau passiert, steht unter WordPress ablösen.
Woher weiß ich, wie groß meine Angriffsfläche ist?
Von außen lässt sich ein Teil davon ablesen: eingesetztes Redaktionssystem, sichtbare Versionen, Schutzkopfzeilen. Dafür gibt es unseren kostenlosen PHP-Sicherheitscheck. Den Rest sieht nur, wer auf das System schaut – dafür gibt es das kostenlose Prüfwerkzeug zum Herunterladen.
Hat DAVINCI am 21. Oktober wirklich nichts tun müssen?
Für die eigene Website nicht, und für die Kundenauftritte, die wir gebaut haben, ebenfalls nicht – sie laufen seit Monaten in derselben Bauweise. Bei einem übernommenen Redaktionssystem, das wir weiter betreuen, lief dagegen dasselbe Programm wie überall. Alles andere zu behaupten wäre unredlich.
Was ist mit unserem Testsystem und den alten Unterseiten?
Das ist erfahrungsgemäß die unangenehmste Frage des ganzen Themas. Vergessene Systeme werden nicht gepflegt, stehen aber im Netz. Mehr dazu in Shared Hosting: Warum Ihre Nachbarn Ihr Problem sind.
Verwandte Themen: Wer hier weiterdenkt, liest bei PHP2Shell betroffen, Incident Response und Angriffsfläche weiter.
Im Text erwähnt
Quellen
- PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet · Wiz Research
- PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit, Cybersicherheitswarnung 2026-297981-1032, Version 1.1 (21.10.2026) · BSIamtlich
- IT-Grundschutz-Baustein APP.3.1 Webanwendungen und Webservices (Edition 2023) · BSIamtlich
- Die Lage der IT-Sicherheit in Deutschland · BSIamtlich
