Wie sicher ist Drupal?

Im Mai 2026 traf eine kritische Lücke über eine Million Drupal-Installationen

Am 20. Mai 2026 veröffentlichte das Drupal Security Team das Advisory SA-CORE-2026-004: eine SQL Injection, die ohne Login ausgenutzt werden konnte. Innerhalb weniger Stunden waren Patches verfügbar, unsere NodeHive SaaS-Lösung war nach 60 Minuten geschützt.

Wie ist das möglich? Nicht durch Glück, sondern durch ein System, das seit über 20 Jahren genau für solche Situationen gebaut wird.

Drupals Sicherheitsarchitektur im Vergleich

Jedes CMS hat Schwachstellen. Der Unterschied liegt darin, wie viele es sind, wie schnell sie behoben werden und wie die Architektur das Schadensausmass begrenzt.

Drupal vs. WordPress: Die Zahlen

Laut dem Sucuri Website Threat Research Report und dem Patchstack State of WordPress Security Report zeigt sich ein klares Bild:

WordPress macht rund 43% aller Webseiten aus und ist das mit Abstand am häufigsten angegriffene CMS. 2023 wurden allein über 5'000 neue Schwachstellen in WordPress-Plugins und -Themes gemeldet. Die grösste Herausforderung: ein riesiges Ökosystem von Drittanbieter-Plugins mit sehr unterschiedlicher Codequalität.
Drupal verzeichnet jährlich deutlich weniger gemeldete Schwachstellen. Das liegt nicht daran, dass weniger gesucht wird, sondern an der strengeren Architektur und einem koordinierten Sicherheitsprozess für beigesteuerte Module.
Typo3 hat ebenfalls ein aktives Security Team und eine solide Bilanz. Im Schweizer Markt ist Typo3 verbreitet, erreicht aber nicht die gleiche Abdeckung durch Drittprüfungen wie Drupal.

Der entscheidende Faktor ist nicht die Zahl der Lücken allein, sondern die Mean Time to Patch: Wie schnell ist ein Fix verfügbar? Bei Drupal liegt diese bei Stunden bis wenigen Tagen. Bei WordPress-Plugins kann es Wochen dauern, bis der Maintainer reagiert.

Was Drupal architektonisch anders macht

Drupal trifft Designentscheidungen, die ganze Angriffskategorien ausschliessen:

Parametrisierte Queries in der gesamten Database API. SQL Injection im Anwendungscode ist damit praktisch unmöglich, nicht weil Entwickler:innen aufpassen, sondern weil die API es gar nicht anders zulässt.
Granulare Rechte und Rollen. Drupal regelt Berechtigungen pro Aktion statt pro Benutzer. Wer einen Beitrag bearbeiten darf, kann deswegen noch lange keine Module installieren. Ein kompromittierter Account richtet dadurch weniger Schaden an.
Strenge Input Validation im Core. Alle Felder durchlaufen Filter gegen Cross Site Scripting (XSS), SQL Injection und Cross Site Request Forgery (CSRF).
Konfiguration als Code. Seit Drupal 8 lässt sich die gesamte Konfiguration als YAML exportieren und versionieren. Unautorisierte Änderungen fallen bei der nächsten Deployment-Pipeline sofort auf.

Das Drupal Security Team

Bereits 2005 hat die Drupal Community ein dediziertes Security Team etabliert. Heute besteht es aus rund 40 Spezialist:innen aus aller Welt, die gemeldete Schwachstellen prüfen, Patches koordinieren und über einen klar definierten Prozess Updates veröffentlichen.

Das Team kümmert sich nicht nur um Drupal Core, sondern auch um den sogenannten "stable" Bereich der beigesteuerten Module. Wer auf gepflegte Module setzt, profitiert vom selben Sicherheitsprozess wie beim Core.

Sicherheitsupdates werden in einem festen Rhythmus veröffentlicht: jeden Mittwoch ist Security Release Day. Betreiber:innen können ihre Wartungsfenster planen und sind nicht von überraschenden Notfall-Updates abhängig. Bei besonders kritischen Lücken wie SA-CORE-2026-004 gibt es zusätzlich eine Vorankündigung (Public Service Announcement), damit alle vorbereitet sind.

Ehrlich gesagt: Wo Drupal Disziplin verlangt

Kein System ist automatisch sicher, und Drupal ist keine Ausnahme. Es gibt einen Bereich, den die Architektur allein nicht abdeckt: beigesteuerte Module ausserhalb des Security-Team-Prozesses.

Drupal hat Tausende von Community-Modulen. Nicht alle durchlaufen den gleichen Sicherheitsprozess. Module ohne "Security Advisory Coverage" werden vom Security Team nicht aktiv geprüft. Wer solche Module einsetzt, übernimmt selbst Verantwortung für deren Codequalität.

In der Praxis heisst das: Modul-Auswahl ist eine Sicherheitsentscheidung. Bei NETNODE prüfen wir für jedes Projekt, welche Module eingesetzt werden, ob sie aktiv gewartet werden und ob sie unter der Security-Advisory-Abdeckung stehen. Module, die diese Kriterien nicht erfüllen, ersetzen wir durch Alternativen oder eigene Lösungen.

Bekannte Vorfälle: Wie Drupal unter Druck reagiert

Nicht die Abwesenheit von Lücken macht ein System sicher, sondern die Reaktion darauf.

Drupalgeddon (2014): SA-CORE-2014-005 war eine kritische SQL Injection in der Database API. Das Security Team stellte den Patch innerhalb weniger Stunden bereit. Bei NETNODE brauchten wir damals 12 Stunden für alle Kundenseiten. Heute geht das deutlich schneller: Unsere standardisierte Infrastruktur mit CI-Pipeline und automatisiertem Deployment ermöglicht es, kritische Patches innerhalb weniger Stunden auszurollen. Unsere NodeHive SaaS-Lösung war beim letzten kritischen Update nach 60 Minuten geschützt. Den vollständigen Ablauf beschreiben wir in So handeln wir bei einem kritischen Drupal Security Update.

Drupalgeddon 2 (2018): SA-CORE-2018-002 (CVE-2018-7600) betraf eine Remote Code Execution im Form API. Alle Drupal 7 und 8 Installationen weltweit waren betroffen, geschätzt über eine Million Seiten. Das Security Team reagierte mit einem Patch innerhalb weniger Tage.

SA-CORE-2026-004 (Mai 2026): Die jüngste hochkritische SQL Injection (CVE-2026-9082) in PostgreSQL-Installationen. Ohne Authentifizierung ausnutzbar. Das Security Team koordinierte den Patch im regulären Mittwoch-Zyklus und kündigte ihn per Public Service Announcement an. Updates stehen für Drupal 11.3.x, 11.2.x, 10.6.x und 10.5.x bereit. Ältere Branches sind End of Life.

Das Muster über die Jahre: gemeldet, geprüft, gepatcht, klar kommuniziert.

CMS-Sicherheit ist jetzt auch eine rechtliche Pflicht

Seit dem 1. September 2023 gilt das revidierte Schweizer Datenschutzgesetz (nDSG). Für Unternehmen, die Webseiten mit Kundendaten betreiben, hat sich damit die Ausgangslage verändert:

Meldepflicht innerhalb von 72 Stunden. Wer eine Datenschutzverletzung feststellt, muss den EDÖB so rasch wie möglich informieren. Ein CMS, das Wochen für einen Sicherheitspatch braucht, wird zum Haftungsrisiko.
Rechenschaftspflicht. Unternehmen müssen nachweisen können, dass sie angemessene technische Massnahmen zum Schutz personenbezogener Daten getroffen haben. "Wir hatten keine Zeit für das Update" ist keine Verteidigung.
Datenschutz-Folgenabschätzung. Bei der Verarbeitung besonders schützenswerter Daten ist eine Risikoanalyse Pflicht. Die Wahl des CMS und dessen Wartungsprozess sind Teil dieser Analyse.

Ein gepflegtes Drupal mit professioneller Wartung erfüllt diese Anforderungen. Ein veraltetes, ungewartetes CMS, egal welcher Hersteller, ist ein offenes Risiko.

Wer setzt auf Drupal?

Die OSS Studie Schweiz 2024 zeigt, dass Drupal in der öffentlichen Verwaltung und in regulierten Branchen stark vertreten ist. Gerade dort, wo Sicherheit, Barrierefreiheit und Datenschutz besondere Anforderungen stellen. Mehr zu den konkreten Zahlen finden Sie in unserem Beitrag Fakten und Zahlen zu Drupal aus der OSS Studie Schweiz 2024.

International setzen unter anderem die Europäische Kommission, zahlreiche US-Bundesbehörden und Universitäten weltweit auf Drupal. Diese Organisationen arbeiten mit sensiblen Daten und unterliegen strengen Compliance-Anforderungen. Drupal wird dort nicht zufällig gewählt.

Sicherheit als laufender Prozess

Eine sichere Drupal-Webseite ist das Ergebnis von kontinuierlicher Wartung, nicht von einmaliger Konfiguration.

Core- und Modul-Updates innerhalb von Stunden. Nicht Tagen, nicht Wochen.
Aktive Überwachung. Logs, Server-Monitoring und ein Frühwarnsystem für ungewöhnliche Zugriffe.
Aktuelle PHP- und Datenbank-Versionen. Drupal lebt nicht im Vakuum. Auch die darunterliegende Plattform muss gepflegt werden.
Backups und Wiederherstellungspläne. Damit ein eventueller Vorfall keine bleibenden Schäden hinterlässt.
Klare Verantwortlichkeiten und dokumentierte Prozesse. Wer entscheidet bei einem kritischen Update? Wer testet, wer deployed? Wer informiert die Kunden?

Ohne diesen Prozess wird auch das sicherste CMS angreifbar. Wir haben unseren Prozess transparent dokumentiert: So handeln wir bei einem kritischen Drupal Security Update.

Viele Unternehmen haben weder die Zeit noch die Kapazität, diesen Prozess intern aufzubauen. Genau dafür bieten wir Drupal Wartung as a Service an, ab CHF 2'500 pro Jahr.

Wer noch auf einer älteren Drupal-Version unterwegs ist, sollte an ein geordnetes Drupal Upgrade denken. Veraltete Versionen erhalten keine Security Updates mehr. Wie eine solche Migration aussieht, zeigt unser Beitrag Drupal 7 zu Drupal 10 Migration.

Lassen Sie uns darüber sprechen

Sie möchten wissen, wie sicher Ihre aktuelle Drupal-Installation wirklich ist? Wir prüfen Ihre Seite, identifizieren Risiken und schlagen einen passenden Wartungsplan vor. Das erste Gespräch ist immer kostenlos.

Jetzt Kontakt aufnehmen