PHP-Sicherheitslücke: Als das halbe Netz offline ging, waren wir für unsere Kund:innen da.
Am 21. Oktober gingen wegen "php2shell" viele Websites offline. Was wir gemacht haben und warum wir mit mehr solcher Tage rechnen.
Was am 21. Oktober passiert ist
Am Mittwoch hat es eine Sicherheitslücke bis in die Nachrichten geschafft. Zwei kritische Schwachstellen in PHP, zusammen „php2shell“ genannt, betreffen die Programmiersprache, auf der auch Drupal läuft. Viele Organisationen haben ihre Websites vorsorglich vom Netz genommen, darunter die Ministerien in Baden-Württemberg, die Universität Freiburg und die Berliner Charité.
Wir auch. Hier lesen Sie, was wir am Mittwoch gemacht haben und was wir daraus für die nächsten Fälle ableiten.
PHP
PHP ist die Programmiersprache, in der Drupal geschrieben ist. Sie läuft auf dem Webserver und erzeugt dort jede Seite, die Ihre Besucher:innen sehen. Eine Lücke in PHP betrifft deshalb jede Website auf dieser Basis, unabhängig vom CMS.
Überblick: Erklärung des Vorfalls – auch was er NICHT war.
Wie so oft neigen Nachrichtenmagazine dazu, solche Themen reißerisch, falsch oder unvollständig darzustellen. Insbesondere bei solchen Medien, die der technischen Welt nicht nah stehen und in sehr kurzer Zeit eine Information zu solchen Sicherheitsvorfällen veröffentlichen müssen, kommt es oft zu inhaltlichen Verzerrungen. Nochmal zusammengefasst also:
Das war der Inhalt des Vorfalls:
- Eine hochkritische Sicherheitslücke in einer der wichtigsten technischen Grundlagen des WWW (Programmiersprache PHP) wurde entdeckt und ein Fix wurde angekündigt.
Die offizielle Sicherheitsmeldung von PHP nennt die Kennungen CVE-2026-109618 und CVE-2026-109619. Die korrigierten Versionen heißen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. - Vorsorglich wurden viele besonders wichtige und gefährdete Websysteme temporär offline genommen, damit die Lücke nicht zwischen dem Zeitpunkt der Veröffentlichung und dem Einspielen eines Fixes ausgenutzt werden kann.
- Nach dem Fix wurden dieses Systeme wieder eingeschaltet.
Das war nicht Inhalt des Vorfalls:
- Es war kein flächendeckender Angriff, der Systeme infiziert oder durch äußere Einflüsse offline genommen hat.
- PHP ist kein System, das unsicherer als andere vergleichbare Softwares wäre.
- Es handelte sich nicht um einen Fehler oder Absturz.
Zeitlicher Ablauf des Fixes bei erdfisch
Das PHP-Team hatte die Sicherheitsupdates am Vortag für 14:00 Uhr UTC angekündigt (16:00 MESZ). Details gab es vorher wenig. Bekannt war nur der Kern: Angreifende können unter bestimmten Bedingungen ohne Anmeldung Schadcode auf einem Webserver ausführen.
Offline vor dem Patch, online direkt danach
Rund eine Stunde bevor die Patches erschienen, haben wir alle Systeme, die wir selbst betreiben, vom Netz genommen. Unsere Kund:innen haben wir vorher darüber informiert.
Warum gingen wir offline?
Das Bundesamt für Sicherheit in der Informationstechnik warnte laut Handelsblatt vor einer „kurzfristigen, großflächigen Ausnutzung“. Auch professionelle Hosting-Partner aus unserem direkten Netzwerk haben dazu geraten, Websysteme temporär offline zu nehmen. Also haben wir gehandelt.
Zwischen Ankündigung und Patch war öffentlich bekannt, dass es eine kritische Lücke gibt. Schließen konnte sie noch niemand. Ein System, das offline ist, bietet in dieser Zeit keine Angriffsfläche. Diese Abwägung haben wir für unsere Kund:innen getroffen: einige Stunden Wartungsseite gegen das Risiko eines kompromittierten Servers.
Als die Patches kamen, haben wir sie eingespielt. Dafür haben Kolleg:innen Extraschichten eingelegt, bis das letzte Update lief. Jedes System, dessen Betrieb wir selbst steuern, ging direkt nach dem Update wieder online. Bei den meisten war das zwischen 20 und 21 Uhr.
Zeitstrahl
Direkte Eingriffe bei schweren Sicherheitsvorfällen sind bei uns selbstverständlicher Teil der Firmenphilosophie.
Sicherheit im Web: Unser Zeitstrahl zu den Ereignissen am 21.10.2026. Wann unsere Systeme offline und wieder online gingen.
Reaktionen unserer Kund:innen
Einige unserer Klienten, die besonders vulnerable und stark frequentierte Websysteme betreiben, waren unterdessen via Chat mit uns in Kontakt. So haben sie unseren Einsatz wahrgenommen:
“Nochmal vielen Dank für die schnelle Reaktion gestern! Heute sind immer noch sehr viele Websites nicht online, daunter viele Kommunen und Behörden. Da waren wir echt schnell, dank euch.”
– Oliver Havlat, Projektleiter Gemeinschaftsauftritt der Verbraucherzentralen
“…ganz herzlichen Dank für diese kollaborative Feuerwehr-Aktion zu später Stunde!”
– Heike Mihm, Heidelberg School of Education
Warum wir zukünftig mit mehr solcher Tage rechnen
Laut Handelsblatt haben Sicherheitsforschende KI eingesetzt. Damit haben sie in einer bislang kaum vorstellbaren Geschwindigkeit aus unscheinbaren Fehlern ein gefährliches Angriffsszenario entwickelt. Dieselben Werkzeuge haben auch Angreifende. Wir rechnen deshalb damit, dass kritische Lücken häufiger kommen und schneller ausgenutzt werden.
Gut, dass wir die richtigen Maßnahmen im Repertoire haben und dagegen gewappnet sind. Das beginnt bei unserem kompetenten und spezialisierten Team und schließt ULF, unser automatisiertes Drupal-Wartungstool, ebenso ein.
Wenn Ihr Wartungspartner bei einer solchen Meldung innerhalb von Stunden handelt, bleibt das Fenster für Angriffe klein. Darauf richten wir unsere Abläufe aus.
ULF wartet auch Systeme in eigener Infrastruktur
Mit ULF warten wir Drupal-Systeme automatisiert. Ein Teil davon läuft bei uns. Ein anderer Teil läuft in den Paketen "ULF Connected" und "ULF Individual" in der Infrastruktur unserer Kund:innen. Den Server betreiben dann Sie oder Ihre IT. Die Wartung des Drupal-Systems übernehmen wir.
Auch diese Kund:innen haben wir am Mittwoch beraten. Die Entscheidung über den Server lag bei ihnen, die Einschätzung dazu kam von uns. Und zwar von denselben Ansprechpartnern, die das Projekt auch sonst persönlich betreuen.
Update Lifecycle Facilitator (ULF)
ULF ist unser Werkzeug für automatisierte Drupal-Wartung. Es prüft Core und Module auf Updates, testet sie automatisch und spielt sie ein. Ob das System bei uns oder bei Ihnen läuft, legt das Paket fest: Premium, Connected oder Individual. Mehr Informationen finden Sie auf der ULF-Produktseite. ▸
Wie wir im Alltag auf Sicherheit schauen
Die Sicherheitsmeldungen des Drupal-Projekts prüfen wir mindestens wöchentlich. php2shell zeigt, warum wir dabei nicht stehen bleiben: Die Lücke saß in PHP selbst und damit einige Ebenen tiefer. Deshalb schauen wir bei Bedarf öfter und gezielt auf Bausteine wie PHP oder Symfony, auf denen Drupal aufsetzt.
Mehr über Drupal- und IT-Sicherheit im Web erfahren Sie hier. ▸
Wir entwickeln fortlaufend Werkzeuge, die uns in solchen Fällen Arbeit abnehmen und Prozesse automatisieren. Unser Ziel: Wir stellen die Sicherheit Ihres Systems immer kurzfristiger und zuverlässiger wieder her.
Fazit: Warum unsere Kund:innen nachts ruhig schlafen
Der Handelsblatt-Artikel schließt mit einem recht wertenden, aber nicht von der Hand zu weisenden Kommentar. Sinngemäß heißt es dort: Wer kein dediziertes IT-Team bezahlen kann oder wem die Zeit fehlt, um sich zukünftig rechtzeitig mit solchen Sicherheitslücken zu befassen, kann deutlich schwerer gefährdet sein. Es könne eine Zwei-Klassen-Gesellschaft entstehen – eben mit jenen, die es sich leisten können, sicher zu sein, und denen, die das nicht können.
Das muss aber nicht sein: ULF und eine aktive Betreuung durch erdfisch ist schon zu erschwinglichen monatlichen Pauschalpreisen erhältlich, die zur Komplexität des Systems und somit auch zur Größe des Businesses passen. Unser Produkt richtet sich an Mittelständler, KMU, Vereine und alle, die sonst ein wichtiges Websystem betreiben, das nicht zuviel Laufkosten verursachen soll.
Sprechen Sie uns an, wenn Sie mit Ihrer Web-Plattform auf der sicheren Seite bleiben wollen.
