Die meisten Drupal-Websitebetreiber, mit denen ich spreche, gehen mit Drupal-Sicherheitsupdates gleich um. Das sind die Fixes, die das Drupal Security Team für Core und Contrib-Module veröffentlicht. Ein Entwickler sieht das Security Advisory. Ein Ticket landet im nächsten Sprint. Der Patch geht ein paar Tage später live, manchmal erst nach zwei Wochen.
Jahrelang hat das gereicht. Heute nicht mehr.
Der Grund ist einfach: KI. Ein Sprachmodell kann einen Sicherheitspatch lesen und daraus einen funktionierenden Angriff schreiben. Im Mai 2026 brauchten Forscher dafür 51 Minuten.
Im Drupal Slack habe ich eine noch kürzere Version gelesen: „Aus jedem SA einen Exploit zu bauen, dauert weniger als 10 Minuten.“
Ich nehme das ernst. In diesem Artikel zeige ich, was sich geändert hat und wie Sie sich auf jedes Security Release vorbereiten. Außerdem erkläre ich, warum Sicherheitsupdates für mich keine Entwickleraufgabe mehr sind. Sie sind eine Aufgabe für ein Support-Team mit Vertrag.
In diesem Artikel:
- Was hat sich bei der Drupal-Sicherheit zwischen 2018 und 2026 geändert?
- Warum ist ein Security Advisory heute eine Anleitung für einen Exploit?
- Was bedeuten schnellere Exploits für Ihre Drupal-Website?
- Wie bereiten Sie sich auf jedes Drupal-Sicherheitsupdate vor?
- Warum sind Drupal-Sicherheitsupdates Aufgabe des Supports und nicht der Entwickler?
- Meine Empfehlung
Was hat sich bei der Drupal-Sicherheit zwischen 2018 und 2026 geändert?
Zwei kritische Lücken im Drupal Core zeigen es am besten. Zwischen ihnen liegen acht Jahre und ein Werkzeug: KI.
Im März 2018 veröffentlichte Drupal SA-CORE-2018-002, bekannt als Drupalgeddon 2. Bis öffentlicher Exploit-Code auftauchte, vergingen etwa zwei Wochen. Hoster hatten Zeit, Schutzmaßnahmen einzurichten. Websitebetreiber hatten Zeit, das Update zu planen.
Im Mai 2026 veröffentlichte Drupal SA-CORE-2026-004. Es war eine SQL Injection im Core, CVE-2026-9082. Forscher von Miggo Security beschrieben, wie sie dafür einen Exploit gebaut haben. Vom Entdecken des Patches bis zum funktionierenden Exploit vergingen 51 Minuten. Sie nutzten Claude und gaben weniger als 10 Dollar für Tokens aus. Ein Mensch musste dem Modell nur an einer Stelle auf die Sprünge helfen.
Zwei Tage später aktualisierte Drupal das Advisory: „exploit attempts are now being detected in the wild.“ Die CISA nahm die Lücke in ihren Katalog Known Exploited Vulnerabilities auf. Imperva zählte mehr als 15.000 Angriffsversuche. Sie trafen fast 6.000 Drupal-Websites in 65 Ländern.
Zwei Wochen im Jahr 2018. 51 Minuten im Jahr 2026. Das ist die ganze Geschichte.
Das Drupal Security Team sieht es genauso. In PSA-2026-10-12 zu einem kritischen Core-Release schrieb es, dass „exploits might be developed within hours or days“. Es bat Websitebetreiber außerdem, am Tag des Releases Zeit für Updates einzuplanen.
Lesen Sie auch: Leitfaden zur Vermeidung von Drupal-Sicherheitsproblemen: Best Practices und proaktive Maßnahmen
Warum ist ein Security Advisory heute eine Anleitung für einen Exploit?
Jedes Security Release liefert den Fix mit. Der Fix ist ein Code-Diff. Der Diff zeigt, welche Funktion verwundbar war. Er zeigt auch, welche Eingaben sie nicht geprüft hat.
Vor der KI brauchte es für einen Angriff aus einem Diff eine erfahrene Person und mehrere Tage Arbeit. Heute liest ein Modell den Diff und findet den verwundbaren Pfad. Es schreibt den Request und testet ihn auf einer frischen Drupal-Installation. Ein Mensch korrigiert unterwegs ein paar Fehler. Die Einstiegshürde ist weg. Die Kosten liegen unter einem Mittagessen.
Angreifer wählen ihre Ziele auch nicht von Hand aus. Sie scannen das Internet nach Drupal-Websites, prüfen die Version und schlagen zu. Deshalb sah Imperva innerhalb weniger Tage Tausende Versuche.
Die Frage lautet also nicht mehr „Wird sich jemand die Mühe machen, uns anzugreifen?“. Die Frage lautet „Wie viele Stunden nach dem Release ist unser Patch live?“.
Was bedeuten schnellere Exploits für Ihre Drupal-Website?
Ich sehe drei Konsequenzen.
Das Release-Fenster ist Ihre Deadline. Sicherheitsreleases für Drupal Core erscheinen mittwochs in einem angekündigten Zeitfenster. Geht Ihr Update erst am Donnerstag live, bleibt Ihre Website einen ganzen Tag offen. Die Scanner laufen dann längst.
Eine Version ohne Support können Sie nicht patchen. Sicherheitsfixes gibt es nur für unterstützte Drupal-Branches. Im Oktober 2026 waren das 11.4.x, 11.3.x und 10.6.x. Drupal 10.5, 11.2 und ältere Versionen sind End-of-Life und bekommen keine Fixes. Läuft Ihre Website auf einer davon? Dann hilft Ihnen am Tag des Releases kein Supportvertrag. Zuerst brauchen Sie ein Drupal-Versionsupgrade auf einen unterstützten Branch.
Der Core ist nur die halbe Arbeit. Am 9. Oktober 2026 veröffentlichte das Security Team an einem Tag 26 Advisories für Contrib-Module. Eines davon war als highly critical eingestuft. Jedes Contrib-Modul auf Ihrer Website ist ein möglicher Einstiegspunkt. Jemand muss diese Advisories lesen, prüfen, welche Ihre Website betreffen, und aktualisieren.
Drupal Steward bietet einen gewissen Schutz. Das Security Team sagt aber klar: nicht gegen alle Exploits. Eine Web Application Firewall verschafft Ihnen Stunden. Den Patch ersetzt sie nicht.
Lesen Sie auch: Wie Sie Drupal 8, 9 oder 10 auf Drupal 11 upgraden
Wie bereiten Sie sich auf jedes Drupal-Sicherheitsupdate vor?
Der größte Teil der Arbeit passiert vor dem Release-Tag, nicht an ihm. So würde ich vorgehen, wenn ich eine Drupal-Website betreiben würde:
- Bleiben Sie auf einem unterstützten Branch. Prüfen Sie Ihre Version jetzt, nicht am Release-Tag. Sind Sie auf einer Version ohne Support, planen Sie das Upgrade sofort.
- Halten Sie sich beim neuesten Patch Release. Das Security Team bittet vor jedem kritischen Release darum. Dadurch ist ein Sicherheitsupdate eine Änderung in einer Zeile. Kein Kampf mit Composer-Abhängigkeiten.
- Halten Sie Staging auf dem Stand der Produktion. Gleiche PHP-Version, gleiche Datenbank, gleiche Module. Lassen Sie Ihre Tests regelmäßig laufen, damit Sie wissen, wie „grün“ aussieht.
- Legen Sie fest, wer deployt und wer freigibt. Namentlich, mit Vertretung. Core-Releases kommen meist am europäischen Nachmittag und Abend. Oft erst, wenn Ihr Team schon Feierabend hat.
- Bereiten Sie einen Rollback vor. Ein Datenbank-Backup und ein getaggtes Release, zu dem Sie in wenigen Minuten zurückkehren können.
- Beobachten Sie nach dem Deployment die Logs. Achten Sie auf ungewöhnliche Requests, neue Admin-Konten und PHP-Dateien im Verzeichnis files.
- Vergessen Sie Contrib nicht. Advisories für Module erscheinen jede Woche, nicht nur zusammen mit Core-Releases.
Nichts davon ist schwer. Alles davon braucht Zeit, Zugänge und jemanden, der das Projekt kennt. Das ist das eigentliche Problem.
Mehr zum Update-Prozess lesen Sie in Drupal-Update: Wie Sie es richtig pflegen. Wenn Sie den Zustand Ihrer Website nicht kennen, beginnen Sie mit einem Drupal-Sicherheitsaudit.
Warum sind Drupal-Sicherheitsupdates Aufgabe des Supports und nicht der Entwickler?
Ein Ticket im nächsten Sprint funktionierte, als ein Exploit zwei Wochen brauchte. Es funktioniert nicht, wenn er 51 Minuten braucht.
Rechnen Sie nach. Ein Angreifer braucht weniger als eine Stunde. Dauert Ihr Update-Prozess drei Tage, verlieren Sie jedes Mal. Sie gewinnen nur, wenn der Patch wenige Stunden nach dem Release live ist. Jedes Mal, ohne Meeting.
Ihre Entwickler können Composer bedienen. An den Fähigkeiten liegt es nicht. Es geht um Kapazität und Verantwortung:
- Jemand verfolgt jede Woche den Drupal-Sicherheitskalender und den Advisory-Feed.
- Jemand hält Staging funktionsfähig, damit ein Patch in Minuten getestet werden kann.
- Jemand hat am Release-Tag Stunden reserviert statt eines vollen Sprint-Backlogs.
- Jemand übernimmt die Verantwortung, wenn das Update um 20:00 Uhr ein Modul kaputt macht.
Ich sehe oft das Gegenteil. Die frühere Agentur „schaut mal drüber“. Oder die eine Person, die die Website kennt, ist im Urlaub. Weitere solche Situationen beschreiben wir in 10 häufige Wartungsprobleme bei Drupal und wie man sie vermeidet.
Sie brauchen ein Team, das für die Website verantwortlich ist. Kein Ticket, das auf ein solches Team wartet.
Meine Empfehlung
Behandeln Sie Drupal-Sicherheitsupdates als Dienstleistung mit Vertrag, nicht als Aufgabe im Backlog. Das bedeutet reservierte Stunden, ein festes Team und eine vereinbarte Reaktionszeit.
Genau dafür ist unser Drupal-Support gedacht. Sie bekommen ein monatliches Paket garantierter Stunden und ein Team, das Ihr Projekt kennt. Dazu kommt ein klarer Prozess für Tage mit kritischen Releases.
Was das in der Praxis bedeutet:
- Monitoring von Sicherheitsupdates. Wir verfolgen Advisories für Core und Contrib. Wir sagen Ihnen, welche Ihre Website betreffen, bevor Sie fragen.
- Reservierte Kapazität. Die Stunden sind im Voraus geplant. Ein Security Release konkurriert nicht mit Ihrem Sprint.
- SLA für Incidents. Garantierte Reaktionszeit bei kritischen Problemen, ab einer Stunde im Enterprise-Paket.
- Umgebungen und Prozess. Staging- und Dev-Umgebungen, Jira Service Desk und Slack. Schätzungen vor Arbeitsbeginn und ein monatlicher Bericht über die genutzten Stunden.
- Keine lange Bindung. Mindestens drei Monate, danach monatlich kündbar.
Nicht sicher, ob Sie Support oder ein dediziertes Team brauchen? Wir vergleichen beides in Entwicklungsteam vs. Support: Welchen Webentwicklungsdienst wählen?.
Soll jemand die Verantwortung für die Sicherheit Ihrer Drupal-Website übernehmen?
So arbeiten wir zum Beispiel mit der Exide Group. Wir haben ihre Website übernommen, die auf einer frühen Version von Drupal 8 basierte und bei der sich Sicherheitspatches nur schwer ohne Regressionen einspielen ließen. Wir haben den Code aufgeräumt und Composer, Testumgebungen und Continuous Integration eingeführt. Seitdem halten wir die Website aktuell und entwickeln sie weiter. Details finden Sie in der Fallstudie zur Exide Group.
Wir arbeiten seit mehr als 15 Jahren mit Drupal und PHP. Wir sind nach ISO 27001:2022 zertifiziert. Das hilft, wenn Ihre Sicherheitsabteilung oder Ihr Einkauf Fragen stellt.
Das nächste kritische Release kommt bestimmt. Sprechen Sie mit uns über Drupal-Support und machen Sie Sicherheitsupdates zur Aufgabe von jemandem.
