Die PHP-Lücke vom 21. Oktober: fünf Lehren, und warum Sicherheit im Büro beginnt

Was ist am 21. Oktober passiert?

Am Mittwoch, dem 21. Oktober 2026, meldete die Organisation hinter PHP zwei schwere Lücken im Kern der Software. PHP ist die Programmiersprache, auf der ein großer Teil aller Websites läuft, vom Webshop bis zur Behördenseite. Über die Lücken konnte jemand ohne Anmeldung eigenen Code auf einem Server ausführen. PHP bewertete beide Lücken mit einem Schweregrad von 9,2 von 10. Alle Versionen ab PHP 5 waren betroffen.

Es gab bereits öffentlichen Beispielcode, der zeigte, wie die Lücke funktioniert. Das NCSC, das niederländische Nationale Cyber Security Centrum, hatte noch keinen Missbrauch gesehen. Es rief Organisationen aber auf, das Update sofort zu installieren, sobald es verfügbar war.

Viele Organisationen gingen kein Risiko ein. Vorsichtshalber gingen unter anderem DigiD, MijnOverheid, die Website der Zweiten Kammer des niederländischen Parlaments und die Website des NCSC selbst offline. Auch Krankenhäuser wie Haaglanden MC und St. Antonius nahmen ihre Websites vorübergehend vom Netz. Um 16.00 Uhr kam das Update. Danach gingen die Websites nach und nach wieder online.

Das NCSC betonte, dass es kein Angriff war, sondern ein Fehler in der Software: „ein Konstruktionsfehler, der in der Software steckt, und so etwas kann passieren“. Das NCSC warnt aber vor langen Nachwirkungen. Bei ähnlichen Lücken suchten Angreifer noch lange nach Systemen, die nicht aktualisiert waren.

Auch bei uns: So sind wir vorgegangen

Auch it-label.com läuft mit PHP. Deshalb haben wir am 21. Oktober das getan, was wir auch anderen raten. Zuerst haben wir geprüft, welche unserer Websites und Systeme betroffen waren. Bis das Update da war, haben wir die Server besonders genau überwacht. Als das Update verfügbar war, haben wir es noch am selben Nachmittag installiert. Danach haben wir geprüft, ob alles wieder richtig funktioniert und ob es Spuren eines Einbruchs gab. Es gab keine.

Mehr Details zu unseren Systemen teilen wir bewusst nicht. Auch das ist eine Lehre: Wie Ihre Sicherheit genau funktioniert, muss nicht jeder wissen.

Fünf Lehren aus der PHP-Lücke

1. Wissen Sie, was Sie haben. Viele Organisationen wussten am 21. Oktober nicht sofort, welche Systeme PHP nutzen. Denken Sie nicht nur an die Website, sondern auch an das Kundenportal, das Intranet, den Webshop und die Verwaltungsoberflächen von Geräten. Wer keinen Überblick hat, weiß auch nicht, was aktualisiert werden muss.
2. Sorgen Sie dafür, dass Sie schnell aktualisieren können. Wer darf ein Update installieren? Wer hat den Zugang? Wie lange dauert es? Legen Sie das fest, bevor es nötig ist. Das gilt auch, wenn Ihre Website bei einem Hosting-Anbieter oder einer Webagentur liegt.
3. Haben Sie einen Plan für den Tag der Lücke. Wer entscheidet, ob eine Website vorsichtshalber offline geht? Wer informiert Kunden und Mitarbeitende? DigiD und die Krankenhäuser haben gezeigt, dass vorübergehend offline zu gehen eine kluge Entscheidung sein kann.
4. Bauen Sie Ihre Sicherheit in Schichten auf. Ein Fehler in einer Schicht darf nicht alles öffnen. Ein Webserver sollte zum Beispiel nicht einfach auf die Dateien, die Buchhaltung oder das Büronetzwerk zugreifen können.
5. Nach dem Update ist es nicht vorbei. Prüfen Sie, ob jemand eingedrungen ist, bevor das Update da war. Und bleiben Sie aufmerksam: Das NCSC erwartet, dass Angreifer noch monatelang nach nicht aktualisierten Systemen suchen.

Software ist nur eine Schicht: Cybersicherheit beginnt im Büro

Bei der PHP-Lücke ging die ganze Aufmerksamkeit an die Software. Das ist logisch, aber es ist nur ein Teil der Geschichte. Ein Angreifer muss nicht immer über das Internet hereinkommen. Manchmal ist die Tür zum Serverraum der einfachste Weg. Darüber haben wir bereits in Die Tür zu Ihrem Serverraum: physische Sicherheit und Warum physische IT-Sicherheit für Cybersicherheit unverzichtbar ist geschrieben.

Stellen Sie sich deshalb auch diese Fragen:

• Ist der Serverraum oder der Netzwerkschrank abgeschlossen? Und wer hat den Schlüssel oder die Zutrittskarte? Oft zeigt sich, dass auch Reinigungskräfte, Installateure oder andere Mieter Zugang haben.
• Sind die WLAN Access Points geschützt? Hängen sie so, dass ein Besucher ein Kabel herausziehen und seinen eigenen Laptop anschließen kann? Gibt es eine Reset-Taste, die jeder drücken kann?
• Ist das Gastnetz getrennt? Gäste, das Büronetzwerk und andere Mieter gehören jeweils in ein eigenes Netzwerk.
• Wo kommt die Internetverbindung ins Gebäude? Und wer hat Zugang zu dieser Stelle? In Gebäuden mit mehreren Firmen teilen sich Mieter oft einen Technikraum.
• Sind die Gebäudesysteme getrennt? Zugangsschleusen, Kameras und Klimatechnik gehören nicht in dasselbe Netzwerk wie die Laptops.
• Gibt es eine Cyber Security Policy? Wer ist dafür verantwortlich? Steht darin, wer Updates macht, wer Zugang zu welchen Systemen hat, welche Absprachen es mit Lieferanten gibt und was Sie bei einer Lücke wie der vom 21. Oktober tun?

Die Antworten auf diese Fragen sehen Sie nicht von Ihrem Schreibtisch aus. Dafür muss jemand vor Ort hinschauen.

Wo das IT-Label hilft

Beim IT-Label Security Audit prüft ein Spezialist vor Ort die Sicherheit Ihres WLAN, Ihrer Netzwerkgeräte, des Serverraums, der Stelle, an der die Internetverbindung ins Gebäude kommt, und der Trennung zwischen Netzwerken. Sie erhalten einen Bericht mit dem, was gut läuft, und dem, was besser sein kann. Mehr dazu lesen Sie in Wie sicher ist die IT Ihres Büros? Neu: das IT-Label Security Audit

Das IT-Label zeigt außerdem, wie ein Gebäude digital übergeben wurde: von der Verbindung und der Verkabelung bis zu den Technikräumen. So wissen Eigentümer und Mieter, wo sie stehen und wer wofür verantwortlich ist.

Häufig gestellte Fragen

War meine Website auch betroffen?

Wenn Ihre Website oder eines Ihrer Systeme PHP nutzt, war es sehr wahrscheinlich betroffen. Alle Versionen ab PHP 5 waren betroffen. Fragen Sie Ihre Webagentur oder Ihren Hosting-Anbieter, ob das Update installiert ist und ob geprüft wurde, dass niemand eingedrungen ist.

Meine Website liegt bei einem Hosting-Anbieter. Muss ich dann etwas tun?

Oft installiert der Hosting-Anbieter das Update. Das ist aber nicht immer so, zum Beispiel bei einem eigenen Server oder einem alten Paket. Fragen Sie deshalb nach. Und legen Sie fest, wer in Zukunft für Updates verantwortlich ist.

Was ist eine Cyber Security Policy, und brauche ich eine?

Eine Cyber Security Policy ist ein Dokument, das beschreibt, wie Ihre Organisation mit digitaler Sicherheit umgeht: wer wofür verantwortlich ist, wer Zugang hat, wie Updates gemacht werden und was bei einem Vorfall passiert. Auch für ein kleines Unternehmen ist eine kurze Version nützlich. Am Tag einer Lücke weiß dann jeder, was zu tun ist.

Prüft das Security Audit auch meine Website?

Nein. Das Security Audit prüft die IT vor Ort: WLAN, Netzwerkgeräte, Serverraum, Anschluss und getrennte Netzwerke. Für Ihre Website oder Software fragen Sie am besten Ihre Webagentur oder Ihren IT-Dienstleister.

Wie weiß ich, ob meine Netzwerkgeräte aktuell sind?

Bitten Sie Ihren IT-Partner um eine Übersicht über Ihren Router, Ihre Firewall, Ihre Switches und Access Points, mit der Softwareversion und dem Datum des letzten Updates. Bei einem Security Audit prüfen wir auch, ob Standardpasswörter geändert wurden und wer die Geräte verwaltet.

Wissen Sie, wo Sie stehen

Die PHP-Lücke hat gezeigt, wie schnell es gehen kann. Wer weiß, was er hat und wer was tut, kann schnell handeln. Beginnen Sie bei der Basis: Ihrem Büro. Fordern Sie ein Security Audit an oder abonnieren Sie den Newsletter und bleiben Sie zur digitalen Sicherheit von Gebäuden auf dem Laufenden.

Quellen: NCSC über Rijksoverheid, Schwere Sicherheitslücken in PHP; NOS, Liveblog 21. Oktober 2026; php.net.