PHP-Lücke: Warum Städte und Kliniken ihre Webseiten abgeschaltet haben

Am Mittwochnachmittag sind in Deutschland reihenweise Webseiten vom Netz gegangen. Städte, Behörden, Kliniken. Nicht weil sie angegriffen wurden, sondern weil niemand sagen konnte, ob es nicht längst passiert war. Wenn Sie in den Nachrichten davon gehört haben und sich fragen, was das für Ihren Betrieb bedeutet: Dieser Beitrag beantwortet genau das.

Die Angaben haben den Stand 22. Oktober 2026 und stützen sich auf die Cybersicherheitswarnung des Bundesamts für Sicherheit in der Informationstechnik vom 21. Oktober 2026.

Was am 21. Oktober passiert ist

Das BSI hat am Mittwoch eine offizielle Cybersicherheitswarnung herausgegeben. Es geht um zwei Schwachstellen in der Programmiersprache PHP, geführt unter den Kennungen CVE-2026-109618 und CVE-2026-109619. Bewertet sind sie mit 9,2 von 10 Punkten. Aus dieser Bewertung lässt sich ablesen, dass für eine Ausnutzung weder eine Anmeldung noch eine Aktion des Nutzers nötig ist.

Das BSI hat empfohlen, Server im Zweifel komplett vom Netz zu nehmen, und die Lage mit der Warnstufe Orange als außerordentlich hoch eingestuft. Mainz und Saarbrücken haben ihre Online-Angebote abgeschaltet, das Städtische Klinikum Braunschweig ebenfalls. Betroffen sind nach aktuellem Kenntnisstand alle bekannten PHP-Versionen, mindestens zurück bis PHP 5. Die Sicherheitsupdates der PHP-Entwickler sind seit Mittwoch 16 Uhr verfügbar.

Was PHP auf Ihrer Seite eigentlich tut

PHP ist keine Software, die Sie irgendwann gekauft haben. Es ist die Technik unter dem Bauch Ihrer Website, und die meisten Geschäftsführer haben davon noch nie gehört, obwohl sie seit Jahren damit arbeiten.

Bei einer PHP-Seite entsteht die Seite erst in dem Moment, in dem jemand sie aufruft. Der Besucher klickt, auf dem Server startet ein Programm, dieses Programm holt Texte und Bilder aus einer Datenbank, setzt daraus die Seite zusammen und schickt sie zurück. Das passiert bei jedem einzelnen Aufruf neu, tausendfach am Tag. WordPress, Shopware, WooCommerce, TYPO3 und Joomla arbeiten alle so.

Aus Ihrer Welt übersetzt ist das Auftragsfertigung. Jeder Kundenanruf fährt die Maschine an. Der Preis dafür: Auf dem Server läuft bei jedem Klick ein Programm, das verarbeitet, was der Besucher mitschickt. Schiebt jemand der Maschine die falsche Zeichnung unter, macht sie, was auf der Zeichnung steht. Genau dort setzen die beiden gemeldeten Lücken an.

Deswegen haben Kommunen und Kliniken ihre Seiten abgeschaltet: Sie konnten auf die Schnelle nicht sagen, ob nicht schon jemand drin war.

In drei Minuten herausfinden, worauf Ihre Seite läuft

Solange Sie nicht wissen, worauf Ihre Website läuft, können Sie die Frage nach der Betroffenheit gar nicht beantworten. Das ist keine Technikfrage, sondern eine Frage von drei Minuten am Telefon.

Rufen Sie Ihren Dienstleister an und stellen Sie zwei Fragen. Erstens: Läuft unsere Seite auf PHP? Zweitens: Ist das Update vom 21. Oktober eingespielt, und wann genau? Lassen Sie sich die Antwort schriftlich geben, eine Mail genügt. Das ist keine Schikane gegenüber Ihrem Dienstleister, sondern Ihr Nachweis, falls später doch etwas passiert.

Wir haben das am Mittwochmorgen für die eigene Seite gemacht, bevor wir irgendetwas anderes angefasst haben. Zwei Minuten, dann war klar, dass nichts zu tun ist. Diese zwei Minuten sind gut angelegt, auch wenn am Ende Entwarnung steht.

Lagerfertigung statt Auftragsfertigung

Unsere Seiten sind anders gebaut, und deshalb ging uns die Meldung nichts an. Sie werden einmal vorher fertig gebaut und liegen danach als fertige Dateien auf den Auslieferungsservern. Ruft jemand die Seite auf, wird diese fertige Datei herausgegeben, mehr passiert nicht. Kein Programm startet, keine Datenbank wird gefragt, nichts verarbeitet die Eingaben des Besuchers. Es gibt schlicht nichts, in das sich fremder Programmcode einschleusen ließe.

Das ist Lagerfertigung. Das Teil liegt fertig im Regal und wird nur noch herausgegeben. Schneller, billiger im Betrieb, und die Maschine, die jemand sabotieren könnte, steht gar nicht erst da.

Diese Bauweise hatte früher einen Preis. Jede Änderung bedeutete, dass die Seite neu gebaut werden musste, und dafür brauchte man einen Dienstleister. Deshalb hat vor zehn Jahren fast jeder zu WordPress gegriffen, trotz des ständigen Update-Aufwands. Heute erledigt die KI diese Änderung in Minuten, und damit fällt der einzige echte Vorteil der alten Bauweise weg.

Was eine statische Seite nicht kann

Der Vollständigkeit halber die Gegenrechnung, denn es gibt Grenzen. Ein Shop mit Warenkorb, Kundenkonten und Zahlungsabwicklung braucht einen Server, der im Moment des Kaufs rechnet. Ein Mitgliederbereich mit Anmeldung ebenso. Wer Ihnen erzählt, eine statische Seite könne alles, hat entweder noch keinen Shop gebaut oder verkauft Ihnen gerade etwas.

In einem unserer laufenden Projekte sieht die Lösung deshalb geteilt aus: Die neue Website wird statisch ausgeliefert, der Shop bleibt beim bisherigen Betreuer auf der bisherigen Technik. Für den Shop gilt die Empfehlung des BSI unverändert weiter, für die Website nicht mehr. Diese Trennung ist kein Kompromiss, sondern die saubere Lösung, weil jeder Teil die Technik bekommt, die er wirklich braucht.

Was heute auf Ihrem Zettel steht

• Der Anruf beim Dienstleister. Zwei Fragen, schriftliche Bestätigung, erledigt.
• Derselbe Anruf beim Shop, falls den jemand anderes betreut. Shopsysteme laufen fast immer auf PHP.
• Die Liste dessen, was sonst noch von Ihnen online ist. Die Landingpage der letzten Kampagne, die alte Testseite, die Seite des Tochterunternehmens. Wenn Sie das nicht aus dem Kopf aufzählen können, ist genau das Ihre Aufgabe für diese Woche, unabhängig von dieser Lücke.
• Bei Anbietern wie Buchungs- oder Newsletter-Diensten müssen Sie nichts tun, dort patcht der Anbieter.

Wenn Sie dabei merken, dass niemand im Betrieb diese Fragen beantworten kann, ist das weniger ein Sicherheitsproblem als ein Zuständigkeitsproblem. Wie wir solche Lücken in Abläufen finden und schließen, zeigen wir in der BOOSTER-Analyse und in der Prozessoptimierung.

Häufige Fragen

Ist meine Website von der PHP-Sicherheitslücke betroffen?

Betroffen sind Webseiten, die auf einem Server mit PHP laufen, und das sind die meisten Firmenwebseiten. Nach aktuellem Kenntnisstand sind alle bekannten PHP-Versionen mindestens zurück bis PHP 5 betroffen. Wenn Ihre Seite mit WordPress, Shopware, WooCommerce, TYPO3 oder Joomla gebaut ist, gehen Sie davon aus, dass sie betroffen ist, bis Ihr Dienstleister Ihnen das Gegenteil bestätigt.

Wie finde ich heraus, ob meine Seite PHP nutzt?

Der schnellste Weg ist der Anruf bei dem Dienstleister oder der Agentur, die Ihre Seite betreut. Fragen Sie, ob die Seite auf PHP läuft und ob das Update vom 21. Oktober 2026 eingespielt ist. Lassen Sie sich beides per Mail bestätigen, damit Sie später einen Nachweis haben.

Haftet mein Hoster oder hafte ich?

Das hängt vom Vertrag ab, und viele Geschäftsführer schätzen das falsch ein. Ein reiner Speicherplatz-Vertrag verpflichtet den Anbieter meist nur zum Betrieb des Servers, die Pflege der Software auf diesem Server liegt beim Kunden. Lesen Sie nach, was Sie beauftragt haben, oder lassen Sie sich schriftlich geben, wer das Einspielen von Sicherheitsupdates schuldet.

Ist eine statische Website wirklich sicherer?

Bei dieser Art von Lücke ja, und zwar nicht ein bisschen, sondern grundsätzlich. Eine statische Seite führt auf dem Server kein Programm aus und fragt keine Datenbank, deshalb gibt es keinen Angriffspunkt für eingeschleusten Programmcode. Andere Risiken wie ein gestohlenes Passwort zum Verwaltungszugang bleiben davon unberührt.

Was kann eine statische Website nicht?

Alles, was im Moment des Aufrufs gerechnet werden muss: ein Shop mit Warenkorb und Zahlung, ein Mitgliederbereich mit Anmeldung, eine Buchungsstrecke mit Verfügbarkeitsprüfung. Solche Teile lassen sich getrennt betreiben oder über einen spezialisierten Anbieter einbinden, während die eigentliche Website statisch bleibt.

Was tue ich, wenn meine Seite schon angegriffen wurde?

Nehmen Sie die Seite vom Netz, bevor Sie etwas anderes tun, und ziehen Sie Ihren Dienstleister hinzu. Prüfen Sie anschließend, ob personenbezogene Daten betroffen sein könnten, denn dann greift eine Meldefrist von 72 Stunden gegenüber der Datenschutzaufsicht. Spielen Sie die Seite aus einer Sicherung von vor dem Vorfall zurück und ändern Sie alle Zugänge.

Webinar am 29. Oktober

Wie eine Website gebaut sein muss, damit solche Meldungen Sie künftig nichts mehr angehen, zeige ich am Donnerstag, 29. Oktober 2026, von 17 bis 18 Uhr im Webinar zu SmartWeb360. Sie bekommen dabei eine moderne Website, die Sie anschließend selbst pflegen, ohne externen Dienstleister, und dieses Problem fällt gleich mit weg. Alle Einzelheiten stehen auf der Seite zu SmartWeb360, die Termine finden Sie unter Events.