Veröffentlicht am 19.07.2026
Zwei Tage. So lange dauerte es, bis Angreifer eine frisch veröffentlichte Sicherheitslücke im Drupal-Core in großem Stil auszunutzen begannen. Am 20. Mai 2026 veröffentlichte das Drupal-Sicherheitsteam Patches für eine hochkritische SQL-Injection-Schwachstelle mit der Kennung CVE-2026-9082. Bereits am 22. Mai registrierten Sicherheitsforscher die ersten aktiven Angriffe. Wenige Tage später nahm die US-Cybersicherheitsbehörde CISA die Lücke in ihren Katalog aktiv ausgenutzter Schwachstellen (KEV) auf. Wer Drupal in Kombination mit einer PostgreSQL-Datenbank betreibt und noch nicht gehandelt hat, muss von einem hohen Kompromittierungsrisiko ausgehen.
In diesem Artikel erklären wir verständlich, was genau passiert ist, ob Sie betroffen sind, wie Sie das in wenigen Minuten prüfen und was Sie jetzt konkret tun müssen – inklusive der DSGVO-Pflichten, die im Ernstfall auf Sie zukommen.
Im Drupal-Core – also der zentralen Software-Basis des beliebten Content-Management-Systems (CMS, ein System zur Verwaltung von Website-Inhalten) – wurde eine sogenannte SQL-Injection-Schwachstelle entdeckt. Bei einer SQL-Injection schleust ein Angreifer eigene Datenbankbefehle in eine Website ein, weil deren Eingaben nicht sauber gefiltert werden. Er kann damit die Datenbank direkt manipulieren, auslesen oder löschen.
Das Besondere und zugleich Gefährliche an CVE-2026-9082: Die Lücke lässt sich ohne jede Anmeldung ausnutzen. Ein Angreifer muss keinen Account besitzen, keine Zugangsdaten erraten und keine Benutzerinteraktion provozieren. Es genügt eine speziell präparierte Anfrage aus dem Internet an die verwundbare Website.
Das Drupal-Sicherheitsteam bewertete die Schwachstelle auf seiner eigenen 25-Punkte-Skala mit dem Höchstprädikat „Highly Critical“. In der offiziellen Meldung (SA-CORE-2026-004) heißt es:
„A vulnerability in this API allows an attacker to send specially crafted requests, resulting in arbitrary SQL injection for sites using PostgreSQL databases. This can lead to information disclosure, and in some cases privilege escalation, remote code execution, or other attacks. This vulnerability can be exploited by anonymous users.“ – Drupal Security Team (SA-CORE-2026-004)
Übersetzt: Angreifer können über manipulierte Anfragen beliebige SQL-Befehle ausführen, was zur Offenlegung von Daten, in manchen Fällen zur Rechteausweitung, zur Ausführung von Schadcode aus der Ferne und weiteren Angriffen führen kann – und das anonym, ohne Login.
Die Schwachstelle steckt in der Datenbank-Abstraktionsschicht von Drupal – das ist die Softwareebene, die zwischen Drupal und der eigentlichen Datenbank vermittelt. Konkret betroffen ist der PostgreSQL-spezifische Teil dieser Schicht (die Datei core/modules/pgsql/src/EntityQuery/Condition.php).
Der Fehler: In einer Programmschleife werden die Schlüssel (Keys) von PHP-Arrays direkt und ungefiltert in SQL-Platzhalternamen übernommen. Da diese Array-Schlüssel aus HTTP-Anfragen – also aus dem, was der Besucher an die Website schickt – stammen können, gelangt vom Angreifer kontrollierter Text unbereinigt in den SQL-Ausdruck. Und zwar bevor die üblichen Schutzmechanismen greifen.
Es gibt zwei bekannte Angriffswege:
Die Angreifer nutzen typische Techniken der blinden SQL-Injection (Boolean-Blind und Time-Based-Blind), bei denen sie über das Verhalten der Website – etwa unterschiedliche Fehlermeldungen oder künstliche Verzögerungen mittels pg_sleep() – Bit für Bit Daten aus der Datenbank extrahieren. Searchlight Cyber, das die Lücke technisch analysierte, beschreibt die Effizienz dieser Methode drastisch:
„One HTTP request per bit, which makes blind extraction of arbitrary data the database user can read practical at scanning speeds.“ – Searchlight Cyber (technische Analyse)
Der von Drupal bereitgestellte Fix ist minimal: An drei Stellen im Code wird nun die Funktion array_values() aufgerufen, um die Array-Schlüssel auf harmlose fortlaufende Zahlen zurückzusetzen. Genau diese Einfachheit des Patches war jedoch Teil des Problems. Satnam Narang von Tenable warnte:
„The minimal complexity of this patch, combined with the availability of AI-powered code analysis tools that can analyze diffs and assist in exploit development, compresses the timeline between patch release and weaponization. Historically, Drupal vulnerabilities of this severity have seen exploitation within hours to days of disclosure.“ – Satnam Narang, Tenable
Betroffen sind Drupal-Installationen der folgenden Versionen – aber ausschließlich, wenn PostgreSQL als Datenbank-Backend eingesetzt wird:
Wichtige Entwarnung für die meisten Betreiber: Rund 99 % aller Drupal-Installationen nutzen MySQL oder MariaDB als Datenbank. Diese Systeme sind von der SQL-Injection nicht betroffen. Nur etwa 1 % der Drupal-Websites setzen PostgreSQL ein – weltweit sind das dennoch geschätzt über 10.000 Websites, vielfach in Enterprise- und Behördenumgebungen, die PostgreSQL bevorzugen.
Zur Einordnung: Drupal betreibt laut SC World weltweit über eine Million Websites. In Deutschland sind es laut BuiltWith rund 21.876 Drupal-Websites. Wenn Sie zu den PostgreSQL-Nutzern gehören, ist Ihre Website akut gefährdet.
Aber auch MySQL-/MariaDB-Nutzer sollten aktualisieren: Dieselben Drupal-Releases enthalten wichtige Sicherheitsupdates für die Komponenten Symfony und Twig. Das Update lohnt sich also in jedem Fall.
Drupal hat am 20. Mai 2026 für alle unterstützten Zweige Patches veröffentlicht. Aktualisieren Sie auf die jeweils passende gepatchte Version:
Mit dem Abhängigkeitsverwalter Composer läuft das Update so ab: composer require drupal/core-recommended:^10.6.9 (bzw. die passende Version) gefolgt von composer update drupal/core --with-dependencies. Anschließend führen Sie drush updb (Datenbank-Updates) und drush cr (Cache leeren) aus. Ohne Composer laden Sie die gepatchte Version von drupal.org herunter und spielen sie manuell ein.
Für diese nicht mehr regulär unterstützten Versionen stellt Drupal manuelle Patch-Dateien bereit (SA-CORE-2026-004-9.5.patch bzw. -8.9.patch). Planen Sie dringend die Migration auf Drupal 10.6 oder 11.3.
Aktivieren Sie in Ihrer Web Application Firewall die SQL-Injection-Erkennungsregeln. Akamais App & API Protector etwa erkennt und blockiert bekannte Exploit-Payloads. Achten Sie besonders auf verdächtige Anfragen an die Endpunkte /jsonapi/ und /user/login.
Für Drupal-Installationen mit PostgreSQL ist das Risiko kritisch. Das ergibt sich aus einer gefährlichen Kombination: Der Angriff funktioniert ohne Anmeldung, funktionsfähige Proof-of-Concept-Exploits waren bereits ab dem Veröffentlichungstag öffentlich verfügbar, und die aktive Ausnutzung ist bestätigt.
F5 Labs dokumentierte zwischen dem 20. und 31. Mai 2026 insgesamt 576 Exploit-Versuche von 9 verschiedenen Quell-IPs:
„The earliest exploitation attempts appeared on May 22, placing the weaponization timeline at roughly two days from publication to active scanning.“ – F5 Labs
Ein Reddit-Bericht spricht sogar von über 15.000 Angriffsversuchen gegen mehr als 6.000 Websites. Die Angriffe sind automatisiert und skalieren auf tausende Ziele gleichzeitig. Shane Barney, CISO bei Keeper Security, bringt es auf den Punkt:
„Attackers are actively scanning for vulnerable targets right now, and once they find one, the path from initial access to privilege escalation is fast and familiar. Security teams shouldn't wait for confirmation of compromise to act.“ – Shane Barney, Keeper Security
Der historische Vergleich ist ernüchternd: Drupalgeddon 2 (CVE-2018-7600) betraf 2018 über eine Million Websites und wurde innerhalb von Stunden nach Bekanntgabe massenhaft ausgenutzt – bis hin zum Einsatz durch Ransomware. Wer heute mit PostgreSQL arbeitet und noch nicht gepatcht hat, sollte von einer hohen Wahrscheinlichkeit einer Kompromittierung ausgehen.
Eine erfolgreiche Ausnutzung kann zur unbefugten Offenlegung, Manipulation oder Löschung aller in der Datenbank gespeicherten personenbezogenen Daten führen – Nutzerdaten, Passwort-Hashes, Kontaktformulareinträge, Bestelldaten. Damit ist die Schwachstelle aus DSGVO-Sicht hochrelevant.
Auch als KMU sind Sie vollumfänglich an die DSGVO gebunden. Deutschland meldet europaweit die höchste Anzahl an Datenpannenmeldungen – über 77.000 kumulativ seit Einführung der DSGVO. Die Aufsichtsbehörden sind aktiv und verhängen auch gegen kleinere Unternehmen Bußgelder.
CVE-2026-9082 ist ein Musterbeispiel dafür, wie schnell aus einer veröffentlichten Schwachstelle ein akuter Notfall wird: Patch am 20. Mai, erste Angriffe am 22. Mai, CISA-Frist für US-Behörden am 27. Mai. Die gute Nachricht ist, dass die überwiegende Mehrheit der Drupal-Betreiber mit MySQL oder MariaDB von der SQL-Injection selbst nicht direkt betroffen ist. Die schlechte Nachricht: Wer PostgreSQL nutzt und nicht gehandelt hat, ist ein leichtes und lohnendes Ziel für automatisierte Angriffe.
Unsere klare Empfehlung: Prüfen Sie noch heute, welche Drupal-Version und welche Datenbank Sie einsetzen. Spielen Sie das Update unverzüglich ein – unabhängig vom Datenbank-Backend, denn die Releases enthalten zusätzlich wichtige Symfony- und Twig-Fixes. Und dokumentieren Sie Ihr Vorgehen, damit Sie im Fall der Fälle Ihre Sorgfaltspflicht nach Art. 32 DSGVO belegen können.