Website-Wartung: Der Ölwechsel, den deine Webseite auch braucht

Heute um 16 Uhr hat das PHP-Team zwei Sicherheitsupdates veröffentlicht. Sie schließen zwei Lücken, die mit 9,2 von 10 Punkten bewertet sind, und das ist eine Zahl, die man in diesem Umfeld selten sieht. Volker Dusch von der PHP Foundation nennt es das schwerwiegendste Problem seit über einem Jahrzehnt und vergleicht es mit Heartbleed.

Eigentlich sollte das erst morgen passieren. Üblich ist ein abgestimmtes Verfahren: erst der Patch, dann die Details, damit Betreiber einen Vorsprung vor Angreifern haben. Dieser Vorsprung ist diesmal gleich zweimal verloren gegangen. Erst machte jemand die Existenz der Lücken in einem Forum öffentlich, woraufhin das PHP-Team den Termin um einen Tag vorzog. Dann veröffentlichte ein Anbieter bereits am Vormittag gepatchte Container-Images, sechs Stunden vor dem offiziellen Release, und wer will, kann aus so einem Patch ableiten, wo der Fehler saß.

Entsprechend früh ging es los. Mehrere Sicherheitsfirmen melden seit dem Nachmittag Angriffsversuche auf ihren Sensoren. Wichtig für die Einordnung: Ein erfolgreicher Einbruch ist bislang von niemandem bestätigt worden. Jake Knott von watchTowr formuliert es so, dass bisher niemand Erfolg hatte, das aber nicht lange so bleiben dürfte.

Ich schreibe diesen Beitrag nicht, weil es eine spannende Sicherheitsmeldung ist. Ich schreibe ihn, weil dieser Fall besser als jede Mahnung zeigt, warum Wartung kein Posten ist, den man streicht.

Wer heute den Stecker gezogen hat

Ein Blick darauf, wie ernst Profis die Lage nehmen, sagt mehr als jede Risikoeinschätzung.

In Deutschland nahm die Charité ihre Website vom Netz, die Stadt Mainz ihr Webportal, die Ruhr-Universität Bochum sperrte den externen Zugriff auf ihre Seiten. In den Niederlanden gingen DigiD, MijnOverheid und die Seite des Parlaments vorsorglich offline. Die Personalsoftware BambooHR schaltete weltweit ab, mitten in der Gehaltsabrechnung.

Das sind Organisationen mit eigenen IT-Abteilungen und Notfallplänen. Sie haben nicht abgeschaltet, weil etwas passiert war, sondern weil sie das Risiko in den Stunden bis zum Patch nicht tragen wollten.

Und dann gibt es die andere Seite. Von den großen deutschen Shared-Hostern, bei denen ein erheblicher Teil der Websites kleiner und mittlerer Unternehmen liegt, habe ich bis heute Abend keine einzige öffentliche Stellungnahme gefunden. Kein Hinweis, kein Patch-Status, nichts. Ob dort gepatcht wurde, erfährt man nur, wenn man nachfragt. Merk dir diesen Punkt, er wird unten wichtig.

Das ist keine Plugin-Lücke

Der Unterschied ist wichtig, und er wird oft nicht verstanden.

Wenn ein WordPress-Plugin eine Sicherheitslücke hat, betrifft das die Websites mit genau diesem Plugin. Du aktualisierst es, fertig. Genau dafür gibt es automatische Updates.

Diesmal sitzt die Lücke eine Etage tiefer. PHP ist nicht Teil von WordPress. PHP ist die Programmiersprache, in der WordPress geschrieben ist und in der es auf dem Server ausgeführt wird. Darunter liegt nur noch der Server selbst.

Das heißt in der Praxis: Ein vollständig aktuelles WordPress schützt dich hier nicht. Wordfence weist ausdrücklich darauf hin, dass die automatischen WordPress-Updates diesen Fix nicht einspielen können. Er muss auf Serverebene kommen, also von deinem Hoster oder von demjenigen, der deinen Server betreut. Dasselbe gilt für Contao, TYPO3, Joomla, Shopware, Magento, Nextcloud und alles andere, was auf PHP läuft.

Und das ist eine Menge. Rund 70 Prozent aller Websites mit bekannter Server-Sprache laufen auf PHP.

Der Ölwechsel

Jetzt zu dem Teil, der über diesen einen Tag hinausgeht.

Ein Auto braucht einen Ölwechsel. Nur braucht es ihn nie an einem bestimmten Tag. Du kannst ihn verschieben, und es passiert: nichts. Du fährst weiter, der Motor läuft, alles wirkt in Ordnung. Du verschiebst ihn noch einmal, und wieder passiert nichts.

Genau das ist die Falle. Das Ausbleiben des Schadens fühlt sich an wie eine Bestätigung, dass die Wartung nicht nötig war. In Wahrheit baut sich etwas auf, das man nicht sieht.

Der Motorschaden kommt nicht nach dem ersten versäumten Wechsel. Er kommt irgendwann, ohne Ankündigung, und er kostet ein Vielfaches von allem, was du vorher gespart hast. Niemand, der je einen Motorschaden bezahlt hat, hält den Ölwechsel danach noch für teuer.

Bei Websites ist es dasselbe, nur mit einem Unterschied, der es schlimmer macht: Beim Auto entscheidet der Verschleiß, wann es so weit ist. Bei deiner Website entscheidet das jemand anderes, nämlich derjenige, der die Lücke findet und ausnutzt. Du hast keinen Einfluss auf den Zeitpunkt.

Warum die Rechnung so selten aufgeht

Das eigentliche Problem zeigt sich bei denen, die zu lange geschoben haben.

Fixes gibt es nur für PHP-Versionen, die noch unterstützt werden, aktuell die Zweige 8.2 bis 8.5. Alles darunter, also PHP 8.1 und älter, bekommt keinen offiziellen Patch mehr.

Nach einer Auswertung von VirusTotal laufen rund 758.000 erreichbare Server auf solchen abgekündigten Versionen. Auf unterstützten Zweigen laufen etwa 272.000. Das heißt: Fast drei Viertel der Server, bei denen sich die Version überhaupt bestimmen ließ, bekommen heute keinen Fix. Bei WordPress sieht es ähnlich aus, dort laufen 36,4 Prozent aller Installationen auf PHP 8.1 oder älter.

Lies die Zahlen noch einmal. Das ist nicht die Nachzügler-Minderheit, das ist die Mehrheit. Es ist der Wagen, für den es keine Werkstatt mehr gibt.

Und diese Server bleiben angreifbar. Nicht heute Abend, nicht diese Woche, sondern dauerhaft, bis jemand sie auf eine aktuelle Version hebt.

Was dabei tatsächlich auf dem Spiel steht

Wer Code auf deinem Server ausführen kann, kann im Grunde alles. Aus vergleichbaren Fällen kennt man die Muster: versteckte Hintertüren, die auch nach dem Patch offen bleiben, neue Administratorkonten, Erpressungssoftware, fremde Inhalte auf deiner Seite, und bei Shops das Abgreifen von Zahlungsdaten direkt im Bestellprozess.

Bei einer der beiden Lücken kommt hinzu, dass ein Angreifer dafür nicht einmal Code ausführen muss. Sie erlaubt auch, Speicherinhalte des Webservers auszulesen, und darin stehen Passwörter und Zugangstoken.

Dazu kommt die rechtliche Seite, die gern übersehen wird. Wenn personenbezogene Daten betroffen sind, und das sind sie bei jedem Kontaktformular und jedem Kundenkonto, musst du den Vorfall nach Artikel 33 DSGVO in der Regel binnen 72 Stunden der Aufsichtsbehörde melden.

Stell das neben die Kosten regelmäßiger Wartung. Die Rechnung ist nicht knapp, sie ist eindeutig. Und sie ist dieselbe wie beim Ölwechsel: Der laufende Aufwand ist planbar, klein und langweilig. Der Schaden ist keins von beidem.

Warum solche Tage häufiger werden

Ein Detail dieses Falls sollte man kennen, weil es die Zukunft betrifft.

Die Lücken wurden mit Hilfe von KI gefunden. Zwei Teams stießen unabhängig voneinander darauf, beide mit aktuellen Sprachmodellen, eines davon im Rahmen eines von OpenAI finanzierten Audits des PHP-Quelltextes. OpenAI rechnet selbst damit, dass solche Funde in den kommenden Monaten deutlich zunehmen.

Das ist erst einmal eine gute Nachricht, denn gefundene Lücken können geschlossen werden. Für dich als Betreiber bedeutet es aber zweierlei. Erstens werden Tage wie dieser nicht seltener, sondern häufiger. Zweitens stehen dieselben Werkzeuge auch der anderen Seite zur Verfügung.

Und noch etwas ist bemerkenswert: Der zugrundeliegende Fehler ist rund 22 Jahre alt. Es gab 2020 eine Meldung dazu, und ein Sicherheitsaudit stieß 2024 erneut darauf, finanziert übrigens mit deutschem Steuergeld über die Sovereign Tech Agency. Die Arbeit an einem Fix blieb dann über Monate liegen. Die PHP Foundation nennt das heute selbst ein strukturelles Versagen.

Mit anderen Worten: Auch die Software, auf der das halbe Netz läuft, hat ihren Wartungsstau. Nur trifft der dann alle gleichzeitig.

Was Wartung wirklich heißt

Wartung ist nicht „ab und zu auf Aktualisieren klicken”. Sie besteht aus vier Dingen.

Erstens: wissen, was läuft. Welche Seiten, welches System, welche PHP-Version, welche Erweiterungen. Dazu gehören auch die vergessenen Dinge: die alte Testseite unter einer Subdomain, das Formular-Tool, der Shop aus dem letzten Projekt. Was niemand auf dem Schirm hat, aktualisiert auch niemand.

Zweitens: wissen, wer zuständig ist. Das ist bei dieser Lücke die entscheidende Frage. Updates am CMS macht vielleicht dein Dienstleister, PHP aber liegt beim Hoster oder beim Serverbetreiber. Wenn du nicht weißt, wer von beiden, dann macht es im Zweifel keiner. Mehr dazu in meinem Beitrag über Hosting.

Drittens: regelmäßig statt anlassbezogen. Ein Termin im Kalender schlägt jeden guten Vorsatz. Genau wie beim Serviceintervall.

Viertens: Backups, die jemand schon einmal zurückgespielt hat. Ein Backup, das nie getestet wurde, ist eine Hoffnung, keine Sicherung.

Was du jetzt tun solltest

Ganz konkret, auch ohne technischen Hintergrund:

1. Finde heraus, auf welcher PHP-Version deine Seite läuft. In WordPress steht das unter Werkzeuge, Website-Zustand, Bericht, im Abschnitt Server. In anderen Systemen weiß es dein Dienstleister oder dein Hoster.
2. Frag deinen Hoster, und gib dich nicht mit Schweigen zufrieden. Eine Zeile reicht: Habt ihr die PHP-Updates vom 21. Oktober eingespielt, und gilt das auch für Server mit PHP 8.1 oder älter? Da die großen Anbieter dazu öffentlich nichts sagen, ist die Nachfrage der einzige Weg zu einer Antwort. Wie schnell und wie klar sie kommt, sagt dir nebenbei einiges über deinen Hoster.
3. Wenn du PHP 8.1 oder älter hast, plane den Wechsel jetzt. Nicht im nächsten Quartal. Für diese Versionen kommt kein Patch.
4. Prüf nach dem Patch, ob er wirklich greift. Die Versionsnummer allein genügt nicht, weil viele Anbieter den Fix in die alte Nummer zurückportieren. Maßgeblich ist, ob die beiden Lücken im Änderungsprotokoll des Pakets genannt sind. Das kann dein Dienstleister in zwei Minuten prüfen.
5. Finger weg von Schnelllösungen. Es kursieren gerade inoffizielle Fix-Plugins und kopierte Code-Schnipsel. Patchstack und Tenable warnen ausdrücklich davor, Letztere auch, weil kursierender Code selbst Schadsoftware enthalten kann.
6. Hinterher hinschauen. Ein Update heute sagt nichts darüber, was vorher passiert ist. Unbekannte Dateien im Webverzeichnis, neue Benutzerkonten, veränderte geplante Aufgaben, ungewöhnlich viele Serverfehler in den Logdateien: Wer prüft das bei dir?

Häufige Fragen

Ich habe WordPress, und die Updates laufen automatisch. Reicht das?

Nein, nicht in diesem Fall. Automatische WordPress-Updates aktualisieren WordPress, nicht PHP. PHP liegt auf der Serverebene darunter und muss von dort aktualisiert werden.

Ich habe eine kleine Seite, da ist nichts zu holen.

Diese Angriffe suchen keine lohnenden Ziele aus, sie durchsuchen automatisiert das halbe Internet nach verwundbaren Servern. Für den Angreifer ist deine Seite kein Ziel, sondern Rechenleistung, Speicherplatz und ein unverdächtiger Absender. Klein zu sein ist kein Schutz.

Mein Hoster macht das doch bestimmt.

Vermutlich. Nur hat sich bis heute Abend keiner der großen deutschen Anbieter öffentlich dazu geäußert. Die Frage lässt sich in zwei Minuten klären, und dann weißt du es, statt es anzunehmen.

Woran erkenne ich, ob meine Seite betroffen war?

Typische Hinweise sind unbekannte Dateien im Webverzeichnis, neue Administratorkonten, fremde Weiterleitungen, Spam-Inhalte in der Google-Suche zu deiner Domain und auffällig viele Serverfehler. Wer sichergehen will, lässt Logdateien und Dateibestand prüfen.

Lohnt sich ein Wartungsvertrag für eine einzelne Firmenwebsite?

Das kommt darauf an, was die Website für dich leistet. Wenn über sie Anfragen, Bewerbungen oder Bestellungen kommen, ist sie Betriebsmittel, und Betriebsmittel wartet man. Wenn sie nur existiert, weil man eine braucht, ist die ehrlichere Frage, ob sie überhaupt richtig aufgesetzt ist.

Mein Fazit

Die heutige PHP-Lücke ist außergewöhnlich, der Mechanismus dahinter ist es nicht. Alle paar Jahre taucht ein Fehler in einer Komponente auf, auf der das halbe Internet aufbaut. Dazwischen liegen die unspektakulären Monate, in denen Wartung wie eine unnötige Ausgabe aussieht.

Genau in diesen Monaten entscheidet sich, wie der Tag ausgeht, an dem es ernst wird. Wer weiß, was läuft, wer zuständig ist und wie schnell gepatcht wird, liest heute eine Nachricht. Wer das nicht weiß, hat möglicherweise ein Problem und merkt es erst Wochen später.

Niemand wechselt gern Öl. Aber jeder, der einmal einen Motorschaden bezahlt hat, macht es danach.

Du weißt nicht, auf welcher PHP-Version deine Seite läuft oder wer bei dir fürs Patchen zuständig ist? Lass uns sprechen, dann klären wir das.