Drupal-Sicherheit gehört zu den wenigen Bereichen der Open-Source-CMS-Welt, in denen der veröffentlichte Prozess besser ist als der Ruf der Plattform. Das Drupal-Sicherheitsteam arbeitet nach einem festen Offenlegungsplan, bewertet jede Meldung auf einer dokumentierten numerischen Skala und koordiniert Fixes über den Core und zehntausende beigesteuerte Projekte hinweg.
Die Bilanz in der Praxis ist schlechter, als dieser Prozess es verdient. Drupal-Websites werden kompromittiert, und die Ursache ist fast nie, dass niemand Bescheid wusste. Die Meldung wurde veröffentlicht, pünktlich, an einem Mittwoch. Der Patch erreichte die Produktion in der Woche darauf. Genau diese Lücke ist das Thema dieses Artikels, und Härtung, Firewalls und Dateirechte existieren alle, um sie überlebbar zu machen oder sie zu verkürzen.
Ihr Risiko bestimmt sich danach, wie schnell Sie patchen, nicht danach, welche Module Sie zufällig betreiben. Core-Meldungen erscheinen in einem monatlichen Mittwochsfenster, Meldungen zu beigesteuerten Projekten jeden Mittwoch, jede davon bewertet auf einer veröffentlichten Skala von 0 bis 25. Hochkritische Core-Lücken wurden innerhalb von Stunden nach der Offenlegung ausgenutzt: Nach der SQL-Injection-Meldung von 2014 lautete die offizielle Empfehlung, jede Website, die nicht binnen sieben Stunden gepatcht war, als bereits kompromittiert zu behandeln. Eine Website, die einen Core-Patch nicht innerhalb eines Arbeitstages ausrollen kann, trägt nahezu das gesamte Risiko, das überhaupt existiert.
Wie der Drupal-Sicherheitsprozess wirklich funktioniert
Die meisten Betreiber einer Drupal-Website haben die Prozessdokumente nie gelesen, und das ist schade: Sie sagen genau, wie viel Vorwarnung Sie bekommen, in welcher Form und an welchen Tagen.
Die Release-Fenster
Das Sicherheitsteam veröffentlicht nach Kalender. Meldungen zu beigesteuerten Projekten gehen jeden Mittwoch heraus. Der Core hat am ersten Mittwoch des Monats ein Fenster für Fehlerkorrekturen und Funktionen und am dritten ein Fenster für Sicherheitsreleases, wie in der Dokumentation zum Zeitplan der Sicherheitsreleases festgehalten. Ein Fenster ist kein Versprechen, dass etwas ausgeliefert wird; es existiert, damit Administratoren wissen, welche Tage sie beobachten müssen.
Gelegentlich gibt es eine Vorankündigung. Vor einem hochkritischen Core-Release kann das Team eine öffentliche Ankündigung veröffentlichen, meist am Montag. PSA-2026-05-18 tat genau das für das Release vom 20. Mai 2026, nannte ein Fenster von 17:00 bis 21:00 UTC und forderte Betreiber auf, zuerst auf das aktuellste Patch-Release ihres Zweiges zu aktualisieren, damit Upgrade-Probleme früh sichtbar werden. Zwei Tage sind die größte Vorwarnung, die Sie bekommen.
Core-Meldungen und Meldungen zu beigesteuerten Projekten
Das sind zwei Systeme mit unterschiedlichen Zusagen. Core-Meldungen decken die unterstützten Minor-Zweige ab, zwei gleichzeitig, den aktuellsten und den davor. In der Praxis bedeutet der Zeitplan der Core-Releases 11.4.x und 11.3.x, wobei 10.6.x noch abgedeckt ist, solange Drupal 10 bis zum Support-Ende am 9. Dezember 2026 läuft. Anfang September 2026 sind die aktuellen Releases 11.4.5, 11.3.16 und 10.6.15. Drupal 12.0.0 und 11.5.0 stehen für die Woche des 7. Dezember 2026 an, ab dann endet die Unterstützung für 11.3.x und 10.6.x.
Die Abdeckung beigesteuerter Projekte ist freiwillig und an Bedingungen geknüpft. Meldungen werden nur für stabile Releases in unterstützten Major-Zweigen jener Projekte herausgegeben, deren Betreuer die Abdeckung beantragt und erhalten haben, geregelt in der Richtlinie zum Advisory-Prozess und zu Berechtigungen. Ein Modul in einer Alpha-, Beta- oder Release-Candidate-Version steht außerhalb des Systems, ebenso eines, dessen Betreuer sich nie angemeldet hat. Keine der beiden Tatsachen ist im Administrationsbereich sichtbar, solange die Website normal läuft.
Das Volumen ist die eigentliche Arbeitslast. Am Mittwoch, dem 26. August 2026, veröffentlichte das Team an einem einzigen Tag zehn Meldungen zu beigesteuerten Projekten, alle mäßig kritisch. Eine Website mit sechzig Modulen wird mehrmals im Jahr genannt, und dieser Strom kostet über die Zeit mehr als die Core-Notfälle.
Der Risikowert, und warum er nicht CVSS ist
Jede Meldung trägt eine Zahl von maximal 25. Die Skala beruht auf dem NIST Common Misuse Scoring System, NISTIR 7864, und ist auf der Seite zu den Sicherheitsrisikostufen dokumentiert. Sechs Metriken fließen ein: Zugriffskomplexität, erforderliche Authentifizierung, Auswirkung auf Vertraulichkeit, Auswirkung auf Integrität, ob ein bekannter Exploit existiert, und die Verbreitung der betroffenen Ziele. Die Bänder laufen von nicht kritisch bei 0 bis 4, wenig kritisch bei 5 bis 9, mäßig kritisch bei 10 bis 14, kritisch bei 15 bis 19 und hochkritisch bei 20 bis 25.
Weil die Zielverbreitung Teil des Wertes ist, landet eine Lücke, die nur eine seltene Konfiguration trifft, niedriger als unter CVSS. SA-CORE-2026-005 vom 17. Juni 2026, ein PHP-Object-Injection-Problem, geführt als CVE-2026-55803, erreichte 18 und wurde genau aus diesem Grund als kritisch und nicht als hochkritisch eingestuft.
Wenn ein beigesteuertes Modul den Support verliert
Das Sicherheitsteam kann einen freiwilligen Betreuer zu nichts zwingen. Wenn ein Betreuer nicht mehr reagiert, sieht das dokumentierte Verfahren vor, das Projekt nach wiederholten Kontaktversuchen als nicht unterstützt zu markieren. Die Projektseite warnt Betreiber dann, eine aktiv gepflegte Alternative zu wählen oder jemanden dafür zu bezahlen, den Fehler zu beheben, damit das Modul wieder veröffentlicht werden kann.
Dieser Rat ist richtig und teuer, denn bis ein Modul als nicht unterstützt markiert wird, ist es meist tragend, und es zu ersetzen bedeutet Datenmigration, Template-Änderungen und einen vollständigen Regressionstest. Der günstige Moment zum Handeln ist das Release vor der Aufgabe, wenn der Betreuer still geworden ist, aber noch nichts kaputt ist, und da schaut fast niemand hin.
Drupal 7 ist am Ende des Lebenszyklus, und Extended Support ist nicht dasselbe wie sicher
Drupal 7 erreichte am 5. Januar 2025 das Ende des Lebenszyklus, bestätigt in PSA-2025-01-06. Nach diesem Datum stellte das Sicherheitsteam Support und Meldungen für den Drupal-7-Core sowie für dessen beigesteuerte Module und Themes ein. Die Ankündigung war ausdrücklich: Sicherheitsprobleme in Drupal 7 dürfen nun ohne Koordination öffentlich gemacht werden, und Zero Days können auftreten.
Es gibt einen kommerziellen Markt für erweiterten Support. Die Drupal Association hat Anbieter zertifiziert, darunter HeroDevs und Tag1 Consulting, im Rahmen eines Extended Security Support Provider Program, und diese liefern tatsächlich Patches. Das ist besser als nichts, aber es ist nicht dasselbe wie unterstützt zu sein. Der Anbieter patcht den Core und eine definierte Menge von Modulen, die er selbst ausgewählt hat, nach eigenem Zeitplan, für zahlende Kunden. Der Rest des Ökosystems, von dem Ihre Website abhängt, liegt außerhalb des Umfangs.
Ein nicht unterstütztes CMS lässt sich außerdem schwer in einem Lieferantenfragebogen oder gegenüber einem Versicherer nach einem Vorfall verteidigen. Unser Leitfaden zu Drupal-Migrationskosten, Wegen und Fristen legt dar, was der Ausstieg kostet.
Das historische Muster: Drupalgeddon und die Folgen
Drei Vorfälle haben geprägt, wie die Community über Patch-Geschwindigkeit denkt. Jeder war eine Injection- oder Remote-Code-Execution-Lücke im Core, und jeder brachte innerhalb von Stunden oder Tagen massenhafte automatisierte Ausnutzung.
Das Sieben-Stunden-Fenster vom Oktober 2014
Das ursprüngliche Drupalgeddon war SA-CORE-2014-005, veröffentlicht am 15. Oktober 2014. CVE-2014-3704 war eine SQL-Injection-Lücke in der Datenbankabstraktionsschicht von Drupal 7, ausnutzbar durch anonyme Benutzer, bewertet mit vollen 25 von 25. Jede Drupal-7-Website unterhalb von 7.32 war betroffen.
Erst die Folgemeldung machte daraus einen Meilenstein. PSA-2014-003 teilte Betreibern mit, dass automatisierte Angriffe binnen Stunden nach der Ankündigung begonnen hatten, ungepatchte Websites zu kompromittieren, und dass sie jede Website, die nicht bis 23:00 UTC desselben Tages gepatcht war, also sieben Stunden nach Veröffentlichung, als kompromittiert annehmen sollten. Nicht möglicherweise kompromittiert. Kompromittiert. Die Meldung warnte, Angreifer könnten sämtliche Daten mitgenommen und Hintertüren installiert haben, und genau das macht aus einem Patch-Problem ein Incident-Response-Problem.
Drupalgeddon 2 und 3
SA-CORE-2018-002, veröffentlicht am 28. März 2018, war CVE-2018-7600: eine Remote-Code-Execution-Lücke über mehrere Subsysteme hinweg in Drupal 7 und Drupal 8, bewertet mit 24 von 25. Betroffen waren Drupal 7.0 bis 7.57 sowie die 8.x-Zweige bis 8.5.0, und öffentliche Exploits folgten innerhalb von rund zwei Wochen.
Vier Wochen später kam SA-CORE-2018-004 am 25. April 2018. CVE-2018-7602 war eine weitere Remote-Code-Execution-Lücke in verwandtem Code, bewertet mit 20 von 25, und die Meldung stellte fest, dass sie bereits aktiv ausgenutzt wurde. Der Abstand ist die Lehre: Websites, die im März gepatcht und dann aufgehört hatten, aufmerksam zu sein, waren im April erneut exponiert.
Mai 2026, und was sich nicht geändert hat
Das Muster ist keine Geschichte. SA-CORE-2026-004 erschien am 20. Mai 2026: CVE-2026-9082, eine SQL-Injection-Lücke, die Websites auf PostgreSQL betrifft, als hochkritisch mit 23 von 25 bewertet und alle Zweige von 8.9 bis 11.3.9 umfassend. Am 22. Mai um 04:30 UTC wurde die Meldung ergänzt, um in freier Wildbahn beobachtete Ausnutzungsversuche zu dokumentieren, keine 48 Stunden von der Veröffentlichung bis zu beobachteten Angriffen.
Nichts davon ist Kritik am Sicherheitsteam. Es gab zwei Tage Vorlauf, lieferte im angekündigten Fenster und aktualisierte die Meldung, als sich das Bild änderte. Der Fehlermodus liegt auf der Betreiberseite: kein eingeübter Weg von einer Meldung zu einer gepatchten Produktionsumgebung.
Wo Drupal-Sicherheit in der Praxis tatsächlich scheitert
Der Core bekommt die Schlagzeilen und ist das kleinste Problem. In den Websites, die wir prüfen, ist der Befund, auf den es ankommt, selten ein ungepatchtes Core-Release, weil Core-Updates im Administrationsbereich auftauchen und jemand sie bemerkt. Die Angriffsfläche liegt woanders.
Die Modulinventur, die niemand hat
Eine typische mittelgroße Drupal-Website betreibt zwischen vierzig und achtzig beigesteuerte Module, jedes mit eigenem Betreuer und eigenem Takt. Die Frage, die fast niemand aus dem Stand beantworten kann, lautet, welche davon noch einen aktiven Betreuer haben, welche von der Advisory-Richtlinie abgedeckt sind und welche seit zwei Jahren keinen Commit mehr gesehen haben. Diese Liste zu erstellen dauert einen Nachmittag.
Das Custom-Modul, für das sich niemand zuständig fühlt
Der häufigste ernste Befund ist ein eigenes Modul, geschrieben von einem Dienstleister, der nicht mehr da ist. Meist tut es etwas Integrationsartiges: einen CRM-Feed, einen maßgeschneiderten Formular-Handler, einen Zahlungs-Callback. Es wurde gegen eine ältere API geschrieben, hat keine Tests, und niemand im Team kann sagen, was es validiert. Eigener Code steht per Definition außerhalb des Advisory-Systems: Keine Mittwochs-E-Mail wird Ihnen sagen, dass er eine SQL-Injection enthält, und der Statusbericht zeigt alles als aktuell. Er braucht dieselbe Review-Disziplin wie jede andere Softwareentwicklung.
Der Stack unter Drupal
Drupal ist PHP, und PHP-Versionen erreichen ihr Lebensende nach eigenem Zeitplan. Eine Website kann auf CMS-Ebene vollständig gepatcht sein und trotzdem auf einer PHP-Version laufen, die vor einem Jahr aufgehört hat, Sicherheitsfixes zu erhalten, weil Hosting nie Teil des Wartungsgesprächs war. Die Anleitung zu Dateirechten und Eigentümerschaft beruht auf dem Grundsatz, dass der Webserver die Dateien, die er ausführt, nicht schreiben können darf, und dennoch laufen viele Websites mit einem beschreibbaren Code-Verzeichnis, weil das ein Deployment-Skript vereinfacht hat.
Wie eine Drupal-Website tatsächlich gepatcht werden sollte
Die Antwort ist langweilig, weshalb sie ungesetzt bleibt. Kein Werkzeug ersetzt den eingeübten Weg von der Meldung in die Produktion, und ihn einmal zu bauen kostet weniger als der erste Notfall.
Der Composer-Workflow
Alles ab Drupal 8 ist ein Composer-Projekt. Aktualisieren Sie die Core-Pakete mitsamt ihren Abhängigkeiten, führen Sie dann die Datenbank-Updates aus und bauen Sie den Cache neu auf:
1composer update "drupal/core-*" --with-all-dependencies
2drush updatedb
3drush cache:rebuild
Drush lässt sich durch update.php ersetzen. Prüfen Sie den Statusbericht davor und danach. Wichtig sind nicht die Befehle, sondern dass sie zuerst irgendwo anders als in der Produktion laufen.
Ein Staging, das wirklich eine Kopie ist
Eine Staging-Umgebung hilft nur, wenn sie die Produktion spiegelt: derselbe Modulsatz, dieselbe PHP-Version, eine aktuelle bereinigte Datenbank. Ein veraltetes Staging liefert ein grünes Ergebnis, das nichts bedeutet, und das ist schlimmer als gar kein Staging, weil es Zuversicht herstellt.
Der Ablauf lautet, die Produktion nach Staging zu ziehen, das Update anzuwenden, die Datenbank-Updates auszuführen, die Seiten und Formulare durchzugehen, die die Website kommerziell nützlich machen, und dann auszurollen. Mit einer funktionierenden Pipeline sind das 45 bis 90 Minuten. Ohne sie anderthalb Tage.
Automatisierung und ihre Grenzen
Automatisierte Abhängigkeits-Updates helfen am meisten beim Strom der beigesteuerten Module, dem Ende mit hohem Volumen und geringer Schwere. Ein Bot, der pro Modul-Update einen Pull Request öffnet und gegen jeden Tests laufen lässt, macht aus einem monatlichen Handdurchgang eine Review-Warteschlange. Der Core geht denselben Weg: Die Arbeit an Automatic Updates baut auf dem Modul Package Manager auf, das im Core ausgeliefert wird, aber noch experimentell ist.
Das realistische Zeitbudget
Eine gepflegte Drupal-Website kostet rund einen halben Tag im Monat an routinemäßigen Modul-Updates, plus ein bis drei Stunden für jedes zutreffende Core-Sicherheitsrelease. Rechnen Sie Reserve für die ein bis zwei hochkritischen Releases im Jahr ein, die noch am selben Abend erledigt werden müssen. Das ist die Zahl, die die meisten internen Teams nie eingeplant haben, weshalb die Arbeit liegen bleibt.
Härtung über das Patchen hinaus
Härtung ersetzt das Patchen nicht. Sie verringert, wie viele veröffentlichte Schwachstellen auf Ihrer Installation ausnutzbar sind, und verschafft Zeit, wenn ein Patch nicht sofort ausgerollt werden kann. Die Drupal-spezifischen Punkte sind billig und dauerhaft.
Trusted Hosts und das Dateisystem
Setzen Sie Trusted-Host-Muster. Drupal nutzt den Trusted-Host-Mechanismus von Symfony, konfiguriert über die Einstellung trusted_host_patterns in der settings.php, als reguläre Ausdrücke für die Domains, unter denen Ihre Website antwortet. Anfragen mit einem anderen Host-Header werden mit 400 abgewiesen. Ohne das kann ein Angreifer über einen gefälschten Header Passwort-Reset-Links und zwischengespeicherte absolute URLs vergiften.
Nutzen Sie das private Dateisystem für alles, was nicht öffentlich lesbar sein soll, und stellen Sie sicher, dass PHP im öffentlichen Dateiverzeichnis nicht ausgeführt werden kann. Drupal liefert eine .htaccess-Datei mit, die die Ausführung unter Apache blockiert, aber nginx hat keine entsprechende Datei zum Ablegen, und die Regel muss von Hand in die Serverkonfiguration geschrieben werden. Websites, die vor Jahren von Apache auf nginx umgezogen sind, haben diesen Schutz häufig unbemerkt verloren.
Wenden Sie dann das Eigentümermodell an: Verzeichnisse auf 750, Codedateien auf 640, das Dateiverzeichnis beschreibbar für den Webserver und für sonst nichts, und die settings.php nur für ihren Eigentümer lesbar.
Berechtigungen, Admin-Routen und der Review-Durchgang
Beschränken Sie die administrativen Routen. Es gibt keinen Grund, warum die Login- und Admin-Pfade einer Website, deren Redakteure aus drei Büros arbeiten, aus dem gesamten Internet erreichbar sein sollten, und eine IP-Freigabeliste oder ein authentifizierender Proxy entfernt eine ganze Klasse von Angriffen auf Zugangsdaten.
Prüfen Sie dann das Berechtigungsraster. Es wächst mit jedem installierten Modul, und der Befund hat fast immer dieselbe Form: eine Redakteursrolle, die Textfilter verwalten darf, oder eine Rolle, die beliebiges PHP ausführen darf. Beides verwandelt ein gestohlenes Redakteurspasswort in Remote-Code-Execution, sodass aus einer Phishing-Mail eine Server-Kompromittierung wird.
Lassen Sie das Modul Security Review laufen, bevor Sie über irgendetwas anderes streiten. Es automatisiert die Prüfungen, die von Hand mühsam sind: Dateisystemrechte, unsichere Textformate, PHP oder JavaScript in Inhalten, offengelegte Fehlermeldungen, Upload-Endungen, fehlgeschlagene Anmeldungen, gefährliche Berechtigungen und die Trusted-Host-Konfiguration. Version 3.1.3, veröffentlicht im Januar 2026, unterstützt Drupal 10.3 und höher neben Drupal 11.
Was eine Firewall bringt und was nicht
Eine Web Application Firewall ist ein virtueller Patch, und genau so positioniert die Drupal Association Drupal Steward, den kostenpflichtigen Dienst, den sie zusammen mit dem Sicherheitsteam betreibt. Er wendet Gegenmaßnahmen auf Netzwerkebene für bestimmte hochkritische Core-Schwachstellen an und schützt eine Website in der Lücke zwischen Meldung und Ausrollen. Der veröffentlichte Preis liegt unter 20 US-Dollar im Monat für eine Website mit einer Million HTTP-Anfragen und unter 100 US-Dollar oberhalb von zehn Millionen.
Die Grenzen benennt das Projekt selbst: Nicht jedes Problem lässt sich so entschärfen, und der Mechanismus deckt nur Schwachstellen ab, die über eine Anfrage an den Webserver ausgenutzt werden. Eine Firewall tut nichts gegen ein kompromittiertes Administratorpasswort, ein bösartiges Modul-Update oder eine Lücke im eigenen Code. Behandeln Sie sie als Versicherung für das Patch-Fenster und nicht als Grund, es zu verbreitern, was auch die Sicht ist, die wir in unserer WordPress-Checkliste zur Sicherheitshärtung vertreten.
Was eine Kompromittierung kostet und wie die Wiederherstellung aussieht
Die Wiederherstellung nach einer Drupal-Kompromittierung ist kein Patch. Sobald ein Angreifer Codeausführung erreicht hat, lautet die Arbeitsannahme, dass Dateien geschrieben, Zugangsdaten mitgenommen und ein Persistenzmechanismus installiert wurden, und genau das sagte das Sicherheitsteam den Drupal-7-Betreibern 2014. Eine kompromittierte Website an Ort und Stelle zu säubern ist Raten im Gewand von Behebung.
Der vertretbare Weg besteht darin, die Codebasis aus der Versionsverwaltung auf einem neuen Host neu aufzubauen, nur Inhalte und hochgeladene Dateien nach Prüfung zurückzuspielen, jede Zugangsberechtigung zu rotieren, die die Website hielt, und das kompromittierte Festplattenabbild aufzubewahren statt es zu löschen. Diesen letzten Schritt lassen Menschen unter Druck aus, und er ist der einzige Beweis dafür, was geschehen ist.
Die kommerziellen Kosten sind selten der Neuaufbau. Es sind die Ausfallzeit, die forensische Arbeit, die Kundenkommunikation und das regulatorische Verfahren. Ein Neuaufbau unter Vorfallsbedingungen kostet typischerweise 5.000 bis 20.000 Pfund an Engineering, meist die kleinste Position in der Gesamtsumme.
Datenschutzpflichten im Vereinigten Königreich
Wurden personenbezogene Daten abgerufen oder könnten sie abgerufen worden sein, beginnt die Uhr der UK-DSGVO in dem Moment, in dem Sie Kenntnis erlangen, nicht wenn Sie die Untersuchung abschließen. Die Leitlinie des ICO zu Datenschutzverletzungen verlangt, dass eine meldepflichtige Verletzung ohne unangemessene Verzögerung und spätestens 72 Stunden nach Kenntniserlangung gemeldet wird, und wenn Sie länger brauchen, müssen Sie Gründe angeben. Ist die Verletzung voraussichtlich mit einem hohen Risiko für die Rechte und Freiheiten natürlicher Personen verbunden, müssen Sie außerdem diese Personen ohne unangemessene Verzögerung informieren.
Der ICO stellt klar, dass ein unvollständiges Bild kein Grund ist, die Frist zu versäumen: Melden Sie, was Sie wissen, und reichen Sie nach. Eine unterlassene Meldung, wo sie erforderlich war, kann ein Bußgeld von bis zu 8,7 Millionen Pfund oder 2 Prozent des weltweiten Umsatzes nach sich ziehen.
Diese Uhr ist der Grund, warum die forensische Frage zählt. Eine Website ohne Logs und ohne Aufzeichnung darüber, welche Version lief, kann nicht sagen, auf welche Daten zugegriffen wurde, und meldet am Ende den schlimmsten Fall. Das ist das Argument für ein Website-Sicherheitsaudit vor einem Vorfall statt danach.
Was ein Drupal-Sicherheitsretainer abdecken sollte
Ein Retainer, der nur verspricht, Updates einzuspielen, ist sein Geld nicht wert, denn Updates einzuspielen ist die leichte Hälfte. Sie zahlen für den Reaktionsweg an dem Tag, an dem eine hochkritische Meldung erscheint, und der Nachweis, dass er funktioniert, ist eine Probe.
Der Umfang, der sein Geld wert ist, deckt die Überwachung der Meldungs-Feeds für genau Ihren Modulsatz ab, einen monatlichen Patch-Zyklus mit Staging, Tests und einem Rollback-Plan, ein vereinbartes Reaktionsfenster außerhalb der Geschäftszeiten für hochkritische Core-Releases, eine vierteljährliche Durchsicht aufgegebener Module mit kalkulierten Ersatzoptionen, die Verfolgung von PHP- und Plattformversionen und eine jährliche Konfigurationsprüfung.
Im Vereinigten Königreich liegen reine Überwachungsvereinbarungen bei etwa 250 bis 450 Pfund im Monat. Ein Retainer mit Staging, Tests und Deployment für eine mittelgroße Website liegt eher bei 600 bis 1.500 Pfund im Monat, skalierend mit der Zahl der Module und dem Umfang des eigenen Codes, weil beide bestimmen, wie viel Regressionstest jeder Zyklus braucht. Gegenüber Agentur-Tagessätzen von 600 bis 900 Pfund kauft das obere Ende dieses Bandes etwa zwei Entwicklertage. Unsere Notiz zu Drupal-Entwicklerpreisen und Auswahl hat die Zahlen.
Das Fenster schließen
Drupal gibt Ihnen mehr Vorwarnung und mehr Struktur als fast jede vergleichbare Plattform. Die Meldungen folgen einem Zeitplan, und die hochkritischen Releases kommen mit zwei Tagen Vorlauf. Nichts davon hilft einer Website, die zwei Wochen braucht, um einen einzeiligen Patch auszurollen.
Mecanik übernimmt Drupal-Patching und Härtung als Teil unseres Website-Sicherheitsaudits und der laufenden Softwareentwicklung. Der erste Auftrag ist meist eine Inventur statt einer Reparatur, weil die meisten Websites nicht sagen können, welche ihrer Module noch unterstützt werden. Wenn Sie die Plattform selbst abwägen, deckt unser Leitfaden zur Drupal-Webentwicklung 2026 das ab.
Häufig gestellte Fragen
Wie oft veröffentlicht Drupal Sicherheitsupdates? Meldungen zu beigesteuerten Projekten erscheinen jeden Mittwoch, und der Drupal-Core hat am dritten Mittwoch jedes Monats ein Fenster für Sicherheitsreleases, wobei ein Fenster kein Release garantiert. Hochkritischen Core-Releases geht meist rund zwei Tage vorher eine öffentliche Ankündigung voraus, die Datum und Zeitfenster nennt.
Was bedeutet ein Drupal-Risikowert von 20 von 25? Drupal bewertet jede Meldung von 0 bis 25 mit einem System auf Basis des NIST Common Misuse Scoring System und kombiniert Zugriffskomplexität, erforderliche Authentifizierung, Auswirkungen auf Vertraulichkeit und Integrität, das Vorhandensein eines bekannten Exploits und die Zahl der betroffenen Websites. Alles zwischen 20 und 25 ist hochkritisch, was bedeutet: noch am selben Tag patchen.
Ist Drupal 7 im Jahr 2026 noch sicher zu betreiben? Nein. Drupal 7 erreichte am 5. Januar 2025 das Ende des Lebenszyklus, und das Drupal-Sicherheitsteam gibt keine Meldungen mehr für Core, beigesteuerte Module oder Themes heraus, sodass Lücken ohne koordinierten Fix öffentlich gemacht werden können. Kommerzieller erweiterter Support deckt eine definierte Menge Code zu den Bedingungen des Anbieters ab, was während einer Migration hilft, aber nicht dasselbe ist wie unterstützt zu sein.
Wie schnell nutzen Angreifer eine Drupal-Schwachstelle aus? Im schlimmsten Fall innerhalb von Stunden. Nach der SQL-Injection-Meldung vom Oktober 2014 forderte das Drupal-Sicherheitsteam Betreiber auf anzunehmen, dass jede nicht binnen sieben Stunden gepatchte Website bereits kompromittiert war. Im Mai 2026 wurden Ausnutzungsversuche gegen eine hochkritische SQL-Injection im Core weniger als zwei Tage nach der Veröffentlichung in freier Wildbahn beobachtet.
Macht eine Web Application Firewall das Patchen von Drupal überflüssig? Nein. Eine Firewall wie Drupal Steward liefert einen virtuellen Patch für bestimmte hochkritische Core-Lücken, die über eine Web-Anfrage ausgenutzt werden, und verschafft damit Zeit im Ausrollfenster. Sie hilft nicht gegen ein gestohlenes Administratorpasswort, ein kompromittiertes Modul oder eine Lücke im eigenen Code, sie verkleinert also das Risiko der Lücke, statt sie zu schließen.
Kommentare