Wir sind offiziell PHP-frei. Das hat uns der Oktober gelehrt (bisher)

Die Woche vom 19. bis 24. Oktober 2026, von Montag bis Samstag, brachte eine stetige Folge ernster Sicherheitsmeldungen aus der ganzen Branche. Wer sie verpasst hat: unser Rückblick auf diese Woche liefert die Details. Die Kurzfassung: In mehreren Fällen waren Angreifer schneller als die Korrekturen.

Eine solche Woche schickt uns nicht zurück ans Reißbrett, aber sie schärft die Linien, die bereits darauf stehen. Es ist eine Sache, ein Prinzip zu vertreten, und eine andere, Fall für Fall zu beobachten, was dort passiert, wo dieses Prinzip fehlt. Statt technische Schritte aufzuzählen, möchten wir deshalb die Prinzipien erklären, nach denen wir arbeiten, denn für Sie als Kunde zählt der Ansatz mehr als jedes einzelne Update. Eines dieser Prinzipien hat gerade seinen Meilenstein erreicht: Wir sind jetzt offiziell PHP-frei.

Warum ist Patchen im Nachhinein ein verlorenes Rennen?

Jahrelang lautete der Standardrat ganz einfach: Patchen Sie schnell, dann sind Sie sicher. Der Trend lief schon damals gegen diesen Rat. Googles Mandiant-Team hat die durchschnittliche Zeit zwischen dem Bekanntwerden einer Schwachstelle und ihrer Ausnutzung gemessen: 63 Tage in den Jahren 2018 bis 2019, 32 Tage über 2021 und 2022 hinweg und fünf Tage im Jahr 2023, als Durchschnitt mit bereinigten Ausreißern.

Fünf Tage ist der Wert aus dem Jahr 2023, bevor KI-Werkzeuge Teil der alltäglichen Softwarearbeit wurden. Dieser Monat lieferte eine frische Messung des Rennens, aufgenommen aus drei verschiedenen Blickwinkeln rund um die PHP2Shell-Offenlegung vom 21. Oktober 2026.

Amazons Threat-Intelligence-Team beobachtete am 17. Oktober einen PHP2Shell-Ausnutzungsversuch, vier Tage vor der öffentlichen Offenlegung, und berichtet, dass nach Ablauf der Sperrfrist und Veröffentlichung des Patches innerhalb von Stunden weitere Proof-of-Concept-Exploits auftauchten. F5 Labs sah die ersten PHP2Shell-Scans mehr als fünf Stunden vor der Veröffentlichung der beiden CVEs (öffentlich katalogisierte Schwachstellen), und innerhalb von Stunden nach der Offenlegung registrierten seine Sensoren Tausende Ausnutzungsversuche. Cloudflares CEO Matthew Prince erklärte am 22. Oktober, Cloudflare habe Tausende Versuche vor der Ankündigung gesehen, Zehntausende in den 45 Minuten danach, Hunderttausende innerhalb von zwei Stunden und Millionen bis zum Zeitpunkt seines Beitrags. Das waren Versuche, keine bestätigten Einbrüche, aber sie zeigen, wie schnell an den Türen gerüttelt wurde: Das Zeitfenster wird inzwischen in Minuten und Stunden gemessen, und für manche schloss es sich, bevor der Patch überhaupt existierte.

Ausnutzung, bevor überhaupt eine Korrektur existiert, ist auch keine Seltenheit. Im Jahr 2023 wurden 70 % der von Mandiant verfolgten ausgenutzten Schwachstellen, 97 von 138, als Zero-Days ausgenutzt, also bevor es irgendeine Korrektur gab.

Wenn die Ausnutzung beginnen kann, bevor ein Patch verfügbar ist, und innerhalb von Minuten nach seinem Erscheinen massenhaft eintrifft, dann kann Patchen, so diszipliniert es auch betrieben wird, nicht der ganze Plan sein. Ein Verteidiger, der sich allein darauf verlässt, ist in ein Rennen eingestiegen, das oft entschieden ist, bevor es beginnt. Wir gehen deshalb davon aus, dass das Rennen manchmal verloren geht, und bauen für den Verlustfall. Aus dieser Annahme werden drei Fragen. Wie viel unserer Systeme kann getroffen werden, solange eine Schwachstelle offen ist? Wie viel kann verloren gehen, wenn etwas getroffen wird? Und wie schnell können wir uns erholen und die Lücke schließen, sobald eine Korrektur existiert? Jedes unserer Prinzipien beantwortet eine dieser Fragen, und alles Folgende ist um sie herum aufgebaut.

Warum entfernen wir Software, statt um sie herum zu patchen?

Beginnen wir mit der ersten Frage: Wie viel kann getroffen werden? Jede Organisation sammelt Software an, die schlecht gealtert ist: Werkzeuge, deren Betreuer weitergezogen sind, Komponenten, die auf alten Versionen festhängen, weil etwas anderes von ihnen abhängt, Code, den niemand anfassen will. Die übliche Antwort besteht darin, solche Software in Behelfslösungen und Firewall-Regeln einzupacken und auf das Beste zu hoffen.

Wir sehen das anders. Software, die nicht aktuell gehalten werden kann, wird entfernt, nicht umgangen. Wir halten sie nicht mit provisorischen Korrekturen am Leben, denn eine provisorische Korrektur an ungepflegtem Code ist ein Versprechen, das irgendwann gebrochen wird. Entweder lässt sich eine Komponente so lange aktualisieren, wie wir sie betreiben, oder sie läuft gar nicht.

Warum scheitern Behelfslösungen? Weil eine Behelfslösung nur die Schwachstellen blockiert, die bereits bekannt sind. Ungepflegte Software hört nicht an dem Tag auf, Schwächen zu haben, an dem ihre Betreuer gehen. Forscher und Angreifer finden Jahr für Jahr neue, und jetzt ist niemand mehr da, der die Korrekturen schreibt. Jede Entdeckung erzwingt eine weitere Regel, einen weiteren Filter, eine weitere Schicht, die auf die letzte geschraubt wird, und der Stapel wird mit jeder Ergänzung zerbrechlicher. Früher oder später taucht eine Schwachstelle auf, die keine äußere Schicht abfangen kann, oder zwei Schichten stören einander, und der Schutz gibt leise nach. Eine Behelfslösung kauft Zeit, und bei aufgegebenem Code gibt es nichts Sinnvolles, wofür man diese Zeit ausgeben könnte, denn das zugrunde liegende Problem wird nie behoben werden.

Denken Sie zurück an das Rennen von oben, das inzwischen in Minuten und Stunden gelaufen wird. Gegen gepflegte Software ist das Rennen brutal kurz, aber es lässt sich wenigstens laufen. Gegen aufgegebene Software gibt es gar kein Rennen, denn die Korrektur, die es beenden sollte, wird nie eintreffen. Niedergeschrieben klingt das selbstverständlich. In der Praxis ist es der härtere Weg, denn etwas zu entfernen bedeutet meist, das neu zu bauen, was darauf aufbaute. Wir halten diesen Preis für gerechtfertigt. Ein Angreifer kann keine Schwäche in einem System ausnutzen, das nicht mehr existiert.

Wie sieht eine kleine Angriffsfläche konkret aus?

Entfernen ist der direkteste Weg, das zu verkleinern, was getroffen werden kann. Die umfassendere Gewohnheit dahinter hat einen Fachbegriff: die Angriffsfläche klein halten. Angriffsfläche ist eine einfache Idee, die Summe aller Stellen, an denen ein Angreifer einen Schlüssel in ein Schloss stecken könnte. Jeder erreichbare Dienst, jede Drittanbieter-Bibliothek, jedes Plugin ist ein weiteres Schloss, das verteidigt werden muss. Unsere Definition guter Sicherheit beginnt hier: Der stärkste Code ist der, den man nicht ausführt, und die sichersten Daten sind die, die man nie gespeichert hat.

Überlegen Sie, was eine Drittanbieter-Bibliothek oder ein Plugin eigentlich ist. Wenn ein Entwickler eine davon einbindet, vertraut er einem Fremden, oft einem unbezahlten Freiwilligen, dass dieser den Code so lange sicher hält, wie er läuft. Die Bibliothek braucht ihre eigenen Updates, ihre eigenen Sicherheitskorrekturen, ihren eigenen aufmerksamen Betreuer. Verliert dieser Betreuer das Interesse, wechselt den Job oder antwortet einfach nicht mehr, läuft der Code weiter, aber niemand schaut mehr hin. Eine danach gefundene Schwachstelle bleibt für immer offen, womit das Aufgabeproblem aus dem vorigen Abschnitt durch eine Seitentür hereinkommt. Multiplizieren Sie das mit den vielen Komponenten, von denen eine typische Anwendung abhängt, und das Bild wird klar. Jede Abhängigkeit ist ein kleines Versprechen von jemandem, den Sie nie getroffen haben, und manche dieser Versprechen laufen leise aus. Wer weniger davon betreibt, schuldet seine Sicherheit weniger Fremden.

Die Systeme, bei denen Sie sich anmelden, über die Sie bezahlen und mit denen unsere Apps sprechen, sind in Go geschrieben. PHP ist verschwunden, und mit ihm der lange Rattenschwanz an Bibliotheken, Plugins und Abhängigkeiten, den PHP-Anwendungen gern hinter sich herziehen.

Wir haben Go für unsere kritischsten Systeme gewählt, weil es das Abhängigkeitsproblem auf Sprachebene beantwortet. Go ist speichersicher: Die Sprache verwaltet den Speicher für den Programmierer, was eine ganze Klasse von Fehlern wie Pufferüberläufe ausschließt, und die US-Cybersicherheitsbehörde CISA führt Go in The Case for Memory Safe Roadmaps unter den speichersicheren Sprachen auf. Diese Klasse ist größer, als sie klingt: Das Chromium-Projekt stellt fest, dass rund 70 % seiner schweren Sicherheitsfehler Speichersicherheitsprobleme sind. Gos Standardbibliothek deckt vieles von dem ab, was ein Webdienst braucht, einschließlich Kryptografie, sodass ein Go-Dienst weniger Drittanbieter-Pakete benötigt, was weniger dieser Versprechen von Fremden bedeutet. Die Kryptografie wird ernst genug genommen, dass Gos eigenes Kryptografiemodul nach dem US-Regierungsstandard FIPS 140-3 validiert ist, CMVP-Zertifikat #5247. Und wenn doch eine Schwachstelle im weiteren Ökosystem auftaucht, pflegt das Go-Sicherheitsteam eine Schwachstellendatenbank, und sein Werkzeug govulncheck meldet nur die Schwachstellen in Code, den ein Programm tatsächlich aufruft, was die Warnungen rauscharm und handlungsrelevant hält.

Das ist wichtig, weil PHP-Installationen so weit verbreitet und so alt sind. W3Techs berichtet, dass PHP von 69,2 % aller Websites verwendet wird, deren serverseitige Sprache bekannt ist, wobei 26,6 % der PHP-Sites noch auf PHP 7 und 7,7 % auf PHP 5 laufen, gemessen am 27. Oktober 2026. Das PHP-Projekt selbst unterstützt jeden Release-Zweig zwei Jahre lang mit Fehler- und Sicherheitskorrekturen und danach zwei weitere Jahre nur mit kritischen Sicherheitskorrekturen. PHP 7 und PHP 5 haben all das hinter sich. Ein großer Teil des Webs läuft auf Code, den seine eigenen Hersteller nicht mehr schützen, womit man freiwillig in das verlorene Rennen aus dem ersten Abschnitt einsteigt.

Unsere Website besteht aus statischen Seiten, die im Voraus erstellt werden, ohne serverseitigen Code, der sie bei Ihrem Besuch erzeugt. Eine Seite, die nur eine Datei ist, bietet sehr wenig Angriffsfläche. Auf die Frage, wie viel getroffen werden kann, ist das unsere Antwort: so wenig wie irgend möglich.

Welche Daten speichern wir über Sie?

Eine kleine Fläche begrenzt, wie ein Angreifer hereinkommen könnte. Die zweite Frage lautet, was er fände, wenn es eines Tages doch einer schaffte. Unsere Antwort besteht darin, den Fund so langweilig wie möglich zu machen: weniger Daten, kürzer aufbewahrt.

Wir fragen nur ab, was für den Betrieb eines Kontos nötig ist. Unsere Datenschutzrichtlinie (auf Englisch) listet es schlicht auf: ein Benutzername, eine E-Mail-Adresse, ein verschlüsseltes Passwort und die bei der Registrierung verwendete IP-Adresse. Zahlungen laufen über externe Zahlungsdienstleister, Ihre Kartendaten liegen also bei Spezialisten, deren gesamtes Geschäft deren Schutz ist, nicht bei uns.

Wir werden auch strenger bei dem, was im Lauf der Zeit geschieht. Alte, ungenutzte Konten werden künftig automatisch gelöscht. Daten, die nicht existieren, können nicht durchsickern, nicht gestohlen und nicht eingefordert werden. Ein Konto, das Sie vor Jahren aufgegeben haben, sollte nicht als Risiko mit Ihrem Namen darauf herumliegen. Sollte das Rennen auf unserer Seite des Zauns je verloren gehen, soll der Preis auf dem Tisch so klein wie möglich sein.

Dieselbe Logik gilt über uns hinaus, denn auch andere Unternehmen verlieren Rennen. Viele der Lecks, unter denen Menschen leiden, passieren bei Shops, Foren und Diensten, bei denen sie sich vor langer Zeit registriert haben. Deshalb bieten wir Benachrichtigungen bei Datenlecks an: Unser Data Breach Scanner prüft bekannte Datenlecks auf Ihre E-Mail-Adresse und schreibt Ihnen eine E-Mail, wenn sie auftaucht, damit Sie Passwörter ändern können, bevor das Leck missbraucht wird.

Was passiert, wenn trotzdem etwas kaputtgeht?

Die dritte Frage hat zwei Hälften: sich erholen und die Lücke schließen. Zuerst die Erholung. Gute Sicherheitsplanung rechnet mit schlechten Tagen. Hardware fällt aus, Lieferanten wechseln, und manchmal ist der richtige Schritt, sich schlicht von einem Stück Infrastruktur zu verabschieden.

Unsere Systeme sind so gebaut, dass sie bei Bedarf neu erstellt oder anderswohin verlegt werden können. Für Sie bedeutet das: Ein Ausfall oder ein Standort, der unseren Ansprüchen nicht mehr genügt, muss nicht in eine lange Unterbrechung münden, denn das betroffene System kann neu aufgebaut oder verlegt werden. Sollten wir je zu dem Schluss kommen, dass eine Umgebung nicht mehr gut genug ist, können wir sie verlassen, statt mit ihr zu verhandeln.

Widerstandsfähigkeit ist keine spektakuläre Eigenschaft. Sie zeigt sich meist darin, dass die Dinge weiterlaufen, und in diesem Bild ist sie das, was aus einer verlorenen Runde keine verlorene Saison werden lässt.

Wie schnell erreichen Korrekturen unsere Systeme?

Die andere Hälfte der dritten Frage ist Geschwindigkeit. Nichts von alledem macht das Patchen überflüssig; es verändert, was das Patchen leisten muss. Mit einer kleinen Fläche und aktueller Software ist das Einspielen einer Korrektur Routine statt Projekt.

Unsere Regel ist einfach: Updates gehen hinaus, sobald Korrekturen existieren. Die Messwerte aus dem Oktober erklären, warum. Wenn Ausnutzungsversuche innerhalb von Minuten und Stunden nach Veröffentlichung einer Korrektur eintreffen, und manchmal bevor eine existiert, schützt eine Korrektur, die wartend herumliegt, niemanden. Wir behandeln einen veröffentlichten Patch als Startschuss. Die Strecke zwischen dem Existieren einer Korrektur und ihrem Einspielen ist der eine Teil des Rennens, den ein Verteidiger vollständig kontrolliert, also ist es der Teil, den wir nicht preisgeben.

Und weil unser Stack klein ist, gibt es schlicht weniger zu patchen, und hier treffen sich die drei Fragen: Je weniger getroffen werden kann, desto schneller schließt sich die Lücke.

Nebeneinandergestellt sehen die Fragen und die Prinzipien, die sie beantworten, so aus:

Was bedeutet all das für Sie?

Es bedeutet, dass die drei Fragen Antworten haben, die Sie spüren können. Weniger Code steht zwischen Ihnen und Ihrem Konto, also gibt es weniger Stellen, an denen etwas schiefgehen kann. Weniger Ihrer Daten existieren, also legt selbst der schlimmste Fall wenig offen. Und unsere Systeme lassen sich neu aufbauen, sodass ein schlechter Tag für uns nicht zu einer langen Unterbrechung für Sie werden muss.

Wir wollen ehrlich sein, was die Grenze all dessen angeht. Das Rennen, mit dem wir begonnen haben, lässt sich nicht zuverlässig gewinnen, weder von uns noch von irgendjemandem, denn Schwachstellen werden manchmal ausgenutzt, bevor irgendjemand von ihrer Existenz weiß, und keine Architektur ändert das. Kein Anbieter kann null Risiko versprechen, und wer es doch tut, verkauft Zuversicht statt Sicherheit. Was wir versprechen können, ist die Form eines Verlusts: wenige Wege hinein, wenig zu holen und ein schneller Weg zurück. Wir können nicht garantieren, dass wir jede Runde des Rennens gewinnen. Wir haben so gebaut, dass eine verlorene Runde Sie so wenig wie möglich kostet, und wir glauben, dass dieses Versprechen, konsequent gehalten, mehr wert ist als ein kühnes, das sich nicht halten lässt.

Sicherheit ist außerdem eine gemeinsame Aufgabe. Auch der stärkste Aufbau, den wir errichten können, profitiert von guten Gewohnheiten auf Ihrer Seite. Wenn Sie praktische Schritte suchen, beginnen Sie mit unserem Leitfaden dazu, wie Sie Ihre Online-Sicherheit erhöhen (auf Englisch). Und wenn Sie einen VPN-Dienst auswählen, bei uns oder anderswo, fragen Sie den Anbieter, wie er denkt, nicht nur, was er verkauft. Die Antwort verrät viel darüber, wie Ihre ruhigen Wochen, und die lauten, verlaufen werden.