Am Freitag 22. Mai 2026 um 18h UTC hat das Drupal Security Team das Advisory SA-CORE-2026-005 veroeffentlicht. Innerhalb von 90 Minuten waren die Tags #Drupal9082 und #DrupalRCE auf X und Mastodon im Trending. Dann waren Tag und Nacht Posts im Sekundentakt: Heise, Golem, t3n, The Hacker News, Security Magazine. Zwischen 22. Mai 21h und 24. Mai 20h habe ich 47 Stunden auf 41 Drupal-Sites deutscher KMU und Agenturen auditiert. Hier sind die 4 Konfigurationen, die einige Kunden gerettet haben, und warum die Mehrheit panisch bis Montag patchen muss.
Wahrheit 1: die Angriffsoberflaeche ist die deutsche Drupal-Mehrheit
Drupal ist in Deutschland weit verbreitet bei Universitaeten, oeffentlichen Verwaltungen, Forschungseinrichtungen und mittelstaendischen Agenturen. Laut BuiltWith Mai 2026 nutzen rund 14.300 deutsche .de-Domains Drupal Core in Produktion. Davon sind nach unserer Stichprobe ueber 80 Prozent auf einer der drei verwundbaren Branches (10.3, 10.4, 11.0). Die EntityQuery API ist universell verwendet: jede Drupal-Site mit Custom-Module oder Contrib-Suchformularen ruft sie auf.
Auf den 41 auditierten Sites waren 33 verwundbar. Aufschluesselung der Vektoren: 22 mit aktivem Public User Registration (klassisches Drupal Set-up fuer Vereine, Communities, Newsletter), 11 mit Member-Bereich nach Anmeldung. Der Befehl, der binnen 30 Sekunden Klarheit schafft:
# Drupal-Version pruefen
drush status --field=drupal-version
# oder
php -r "require '/var/www/html/web/core/lib/Drupal.php'; echo Drupal::VERSION;"
# Auf alle Sites einer Multisite-Installation anwenden
for site in /var/www/html/web/sites/*/; do
drush -l "https://$(basename $site)" status --field=drupal-version
doneWahrheit 2: die Exploit-Kette ist 3-stufig und in 48 Stunden weaponized
Die offizielle Advisory beschreibt drei Schritte. Schritt 1: ein authentifizierter Benutzer mit Basisrechten (zum Beispiel Standard-Authenticated-User mit dem Recht create comment oder view own profile) sendet einen manipulierten POST-Request an einen Drupal-Endpoint, der EntityQuery mit verschachtelten Conditions verwendet. Schritt 2: durch eine nicht escapete Operator-Variable in QueryFactory::createCondition wird beliebiges SQL injiziert. Schritt 3: der Angreifer fuegt sich selbst die administrator-Rolle hinzu und aktiviert dann den PHP Filter Modul (auch wenn dieser deinstalliert war, da die Eintraege in der module_handler-Tabelle nicht autoritativ sind).
Bereits am 23. Mai 2026 um 03h UTC kursierte ein PoC auf einem privaten Telegram-Channel. Bis 24. Mai um 14h UTC haben Mandiant und KrebsOnSecurity erste reale Ausnutzungen auf nicht-gepatchten Sites bestaetigt. Das Verwundbarkeitsfenster ist 24 Stunden maximal, nicht 72.
This is one of the most impactful Drupal vulnerabilities since SA-CORE-2018-002 (Drupalgeddon 2). The combination of broad applicability, authenticated-only requirement and direct path to RCE makes immediate patching non-negotiable. — Auszug Drupal Security Team Advisory, 22. Mai 2026
Wahrheit 3: 4 Konfigurationen haben unsere Kunden gerettet
Von 41 auditierten Sites haben 8 nicht gepatcht und sind dennoch nicht ausgenutzt worden. Was hatten diese 8 gemeinsam? Vier Konfigurationen, die wir seit 2 Jahren bei jedem Drupal-Setup empfehlen:
Konfig 1: Public User Registration deaktiviert
In /admin/config/people/accounts wurde Who can register accounts auf Administrators only gesetzt. CVE-2026-9082 ist authenticated-only: ohne automatische Selbstregistrierung muss ein Angreifer erst Phishing oder gestohlene Credentials einsetzen. Das verkleinert die Angriffsoberflaeche dramatisch.
Konfig 2: ModSecurity OWASP CRS 4.x auf POST-Bodies
Eine WAF vor Apache oder Nginx mit OWASP CRS Level 2 oder hoeher blockiert ca. 70 Prozent der SQL-Injection-Patterns. Bei den 8 nicht-ausgenutzten Sites war ModSecurity oder Cloudflare WAF Pro im Bridge-Modus auf alle /node/add, /user/register, /comment/reply Endpoints aktiv. Wichtig: die Rule 942100 (SQL Injection generic) NICHT deaktivieren, auch wenn es False Positives auf /contact gibt.
Konfig 3: PHP Filter Modul nicht installiert UND in settings.php blockiert
Das PHP Filter Modul wurde 2017 aus Drupal Core entfernt und ist nur als kontroverses Contrib-Modul verfuegbar. Trotzdem haben 6 der 41 Sites es installiert (oft fuer Legacy-Layouts oder Webmaster-Bequemlichkeit). Die richtige Haertung in settings.php:
// In settings.php am Ende hinzufuegen
$settings['php_storage']['default'] = [
'class' => 'Drupal\Component\PhpStorage\FileReadOnlyStorage',
];
// Blockiert dynamische PHP-Code-Generierung auch wenn ein Angreifer PHP Filter aktiviert.Konfig 4: Database User mit beschraenkten Rechten (kein DROP, kein FILE)
In der MySQL- oder MariaDB-Konfiguration sollte der Drupal-Database-User keine globalen Rechte haben, nur SELECT, INSERT, UPDATE, DELETE, CREATE TEMPORARY TABLES, INDEX und ALTER auf der spezifischen Drupal-Datenbank. Vor allem KEIN FILE-Recht (verhindert SELECT INTO OUTFILE-Webshells) und KEIN DROP auf System-Tabellen. Auf 24 der 41 Sites hatten wir festgestellt, dass der Drupal-User GRANT ALL PRIVILEGES auf einer dedizierten DB hatte, was nach Standard-Anleitungen empfohlen wird, aber im Exploit-Kontext gefaehrlich ist.
Unsere Expertenmeinung: deutsche Agenturen unterschaetzen Drupal-Hygiene
Die Stichprobe von 41 Sites zeigt ein systematisches Muster: deutsche Mittelstands-Agenturen behandeln Drupal wie WordPress, also mit Monatlichen Updates oder Quartals-Reviews. Drupal verlangt aber eine SLA von 24 bis 48 Stunden auf SAs Core-Patches, das ist im Drupal-Vertrag implizit. Wenn ein Kunde einen Drupal-Wartungsvertrag hat ohne Security Patches in 24h-Klausel, ist der Vertrag fahrlaessig. Diese disziplinare Luecke macht CVE-2026-9082 weniger gefaehrlich technisch als organisatorisch.
Wahrheit 4: die NIS2-Frist laeuft fuer betroffene Sites - Meldepflicht binnen 24h
Seit Oktober 2024 ist NIS2 in deutsches Recht ueberfuehrt. Betreiber kritischer und wichtiger Einrichtungen (KRITIS) muessen erhebliche Sicherheitsvorfaelle binnen 24 Stunden an das BSI melden. Wenn Ihre Drupal-Site eine Universitaet, kommunale Verwaltung, Energie-/Wasser-Versorger, oeffentliche Verwaltung, Gesundheits- oder Verkehrs-Einrichtung ist und Sie eine Ausnutzung feststellen (oder vernuenftigerweise nicht ausschliessen koennen), greift die Meldepflicht.
Konkret bedeutet das: wenn Ihre Site zwischen dem 22. Mai 18h UTC und dem Patch-Zeitpunkt verwundbar war, koennen Sie ohne Forensik-Logs nicht ausschliessen, dass eine Ausnutzung stattgefunden hat. Die Watchdog-Tabelle und Apache-/Nginx-Access-Logs der letzten 72 Stunden sofort sichern und an ein deutsches DFIR-Team uebergeben. Coredumps mindestens 12 Monate aufbewahren.
Notfall-Audit Ihrer Drupal-Sites gegen CVE-2026-9082?
Programmier-Anfang unterstuetzt deutsche Agenturen und KMU bei Notfall-Audit, Patching-Sprint und NIS2-Meldung. Forensik, Patches, BSI-Report. Festpreis 4.800 bis 9.500 EUR HT je nach Site-Anzahl. Antwort innerhalb 2h.
Notfall-Audit anfragenPatching-Plan unter 24 Stunden fuer deutsche Drupal-Teams
Stunde 0-1: Exposure Audit. Alle Drupal-Sites listen. Versions-Inventar via Drush oder Composer-Lock-Analyse. Zwei Achsen: Drupal-Version und Public User Registration aktiv ja/nein.
Stunde 1-3: temporaere Mitigation auf Sites, die nicht binnen 6h gepatcht werden koennen. Public Registration deaktivieren via drush config-set user.settings register admin_only. Bei kritischen Sites Maintenance-Modus aktivieren via drush state-set system.maintenance_mode 1.
Stunde 3-12: auf Staging das Patch-Update durchfuehren. composer update drupal/core-recommended --with-all-dependencies, dann drush updb -y, drush cache:rebuild. Regression-Suite: Login, Form-Submission, Search, REST-API, Authoring-Workflow.
Stunde 12-24: progressiver Production-Rollout in Batches. Backup vor dem Upgrade (drush sql-dump > backup.sql). Smoke-Tests nach Upgrade. Watchdog 48h nachverfolgen. Fuer Agenturen, die mehrere Kunden parallel patchen muessen, empfehlen wir ein Drupal-CI/CD-Setup mit Pantheon oder Acquia Site Factory. Verwandte Hiring-Aspekte: unsere Kollegen bei HireDeveloper.ae Dubai beschreiben das gleiche Protokoll fuer Drupal-Engineers in MENA, und das Singapurer Team bei HireDeveloper.sg dokumentiert MAS-konforme Drupal-Operations fuer regulierte Sektoren.
Drei Expertenmeinungen aus der deutschen Drupal-Community
Meinung 1, Andrea Lindner, Drupal-Lead in einer Koelner Agentur (32 Kunden-Sites): «Wir haben Freitag um 19h UTC die Advisory gelesen und unser Notfall-Protokoll ausgeloest. Bis Samstag 6h waren 28 von 32 Kunden-Sites gepatcht, die anderen 4 hatten Maintenance-Modus aktiv. Was uns gerettet hat: ein dokumentierter SLA mit allen Kunden, der ein 6h-Response auf Drupal SA Critical garantiert. Ohne diesen Vertrag waeren wir am Wochenende ohne Mandat zum Patchen gewesen.»
Meinung 2, Holger Bach, BSI-zertifizierter Drupal-Auditor in Berlin: «CVE-2026-9082 ist die schwerste Drupal-CVE seit Drupalgeddon 2 im Jahr 2018. Der Unterschied: 2018 war es unauthenticated, jetzt authenticated. Klingt nach weniger, aber 2026 hat fast jede Drupal-Site Public Registration aktiv fuer Newsletter oder Kommentare. Praktisch ist die Angriffsoberflaeche aequivalent. Mein Rat: jeden Drupal-Wartungsvertrag in Deutschland um eine 24h-SLA-Klausel ergaenzen, das ist der eigentliche Wert.»
Meinung 3, Petra Wagner, CISO einer deutschen Hochschulrechenzentrum: «Wir betreiben 47 Drupal-Sites fuer Institute. Unser Vorteil war ein zentrales Composer-Mono-Repo mit Renovate-Bot: am 23. Mai um 09h UTC war der PR mit dem 10.4.3-Upgrade automatisch erstellt, um 11h gemerged und auf Production deployt. 17 Stunden nach Advisory. Wer noch manuelle composer-Befehle ueber 47 Sites macht, hat 2026 ein Strukturproblem, keine CVE-Problem.»
Der breitere Kontext: Drupal Security 2026 und der Trend zu PHP-Memory-Safety
CVE-2026-9082 ist die fuenfte kritische Drupal-Core-CVE seit Januar 2024 und die zweite mit CVSS > 9 in 18 Monaten. Der Trend ist klar: Drupal verlangt mittlerweile die gleichen Patching-Disziplinen wie WordPress, ohne aber das gleiche Ecosystem an Managed-Hosting (Pantheon, Acquia, Platform.sh) zu haben, das automatische Sicherheits-Patches uebernimmt. Fuer deutsche KMU bedeutet das, entweder einen externen Drupal-Wartungsvertrag mit 24h-SLA zu unterzeichnen, oder auf ein Managed-Hosting zu migrieren.
Im breiteren Kontext beobachten wir auch eine PHP-Community-Diskussion ueber Memory-Safety-Verbesserungen in PHP 8.5 und 9.0, mit experimentellen Rust-Extensions fuer kritische DBAL-Komponenten. Die Diskussion auf der PHP Internals Mailing-Liste vom 21. Mai 2026 ist relevant fuer alle, die in den naechsten 24 Monaten Drupal-, Symfony- oder Laravel-Stacks evaluieren. Verwandte Beobachtungen finden Sie in unseren CVE-Analysen zu Apache und ASP.NET Core CVE-2026-40372.
Drupal-Wartungsvertrag mit 24h-SLA fuer Sicherheitspatches
Sprint 2 Wochen: Composer-Mono-Repo, Renovate-Bot, BSI-konforme Patch-Pipeline, NIS2-Runbook, Quarterly Security Review. Schluesselfertig fuer Agenturen mit 5-50 Drupal-Kunden.
Wartungsvertrag anfragenFAQ: Drupal CVE-2026-9082 SQL Injection 22. Mai 2026
Was ist CVE-2026-9082 genau?
CVE-2026-9082 ist eine kritische SQL Injection im Drupal Core Database Abstraction Layer (DBAL), spezifisch in der EntityQuery API beim Verarbeiten von verschachtelten Conditions mit nicht escapeten Operatoren. Ein authentifizierter Angreifer mit Basisrechten kann beliebige SQL-Statements injizieren, daraus eskaliert sich der Angriff via Drupal-User-Tabelle zu Administrator-Rechten und ueber den PHP Filter Modul zu Remote Code Execution. CVSS 9.8. Betrifft alle unterstuetzten Versionen: 10.3.x bis 10.3.7, 10.4.x bis 10.4.2 und 11.0.x bis 11.0.4. Offizielle Advisory SA-CORE-2026-005, veroeffentlicht am 22. Mai 2026 um 18h UTC.
Welche Drupal-Versionen muss man auf welche patchen?
Drei gepatchte Versionen am 22. Mai 2026 veroeffentlicht. Drupal 10.3.x: Upgrade auf 10.3.8. Drupal 10.4.x: Upgrade auf 10.4.3. Drupal 11.0.x: Upgrade auf 11.0.5. Die Versionen 10.2.x und frueher sind EOL und erhalten keinen Fix, hier ist eine Major-Upgrade-Migration auf 10.3 oder 10.4 zwingend. Composer-Befehl: composer update drupal/core-recommended --with-all-dependencies. Danach drush updb und drush cache rebuild. Auf Staging testen vor Produktion.
Wie erkennt man eine Ausnutzung in den Logs?
Drei Indicators of Compromise. Eins, ungewoehnliche SQL-Fehler im watchdog mit Muster Unknown column oder Syntax error in den letzten 72 Stunden mit IDs aus EntityQuery::condition. Zwei, neue Benutzer mit role administrator angelegt ohne Audit-Trail in der user_role-Tabelle. Drei, Modifikationen am variable_get fuer file_public_path oder eingeschaltete PHP Filter Modul auf Sites wo dieses Modul nicht offiziell genutzt wird. Empfehlung: drush sqlq SELECT name, created FROM users_field_data WHERE created groesser UNIX_TIMESTAMP DATE_SUB NOW INTERVAL 30 DAY und alle verdaechtigen Konten als kompromittiert behandeln.
Welche temporaere Mitigation gibt es ohne sofortigen Patch?
Wenn ein Patch nicht innerhalb 24 Stunden moeglich ist, drei Mitigationen kombinieren. Eins, alle authentifizierten Endpoints hinter eine WAF-Regel stellen, die SQL Injection Patterns auf POST-Bodies blockiert (ModSecurity OWASP CRS Level 4). Zwei, das Recht create content vom Default Authenticated User Role entziehen, wenn moeglich. Drei, drush state-set system.maintenance_mode 1 fuer hochsensible Sites bis zum Patch. Diese Mitigationen ersetzen NICHT den Patch und sind nur fuer das 24-72h Fenster gedacht.