Drupal CVE-2026-9082 Zwingt PostgreSQL-Betreiber zum Notfall-Patching

Jeder Platform-Verantwortliche, der einen Drupal-on-PostgreSQL-Stack betreibt, hat jetzt eine ungeplante Position im Budget für Mai. Das Drupal-Sicherheitsteam hat Notfall-Releases für sechs unterstützte Versionszweige veröffentlicht und zusätzlich Best-Effort-Patches für zwei End-of-Life-Branches bereitgestellt, um eine Schwachstelle zu schließen, die anonymen Nutzern beliebige SQL-Injection ermöglicht. Die eigentlich interessante Frage für Entscheider ist nicht, ob man diese Woche patchen soll. Es geht darum, was dieser Vorfall für die Build-vs-Buy-Kalkulation von Teams bedeutet, die Drupal im Jahr 2026 noch als strategisches CMS einsetzen.

Was Passiert Ist

Am 21. Mai 2026 meldete das Drupal-Projekt eine als „hochkritisch" eingestufte Schwachstelle in Drupal Core, verfolgt als CVE-2026-9082. Wie The Hacker News berichtete, hat der Fehler laut CVE.org einen CVSS-Score von 6,5 – was merkwürdig niedrig erscheint im Vergleich zur projekteigenen Einstufung als „hochkritisch". Diese Diskrepanz ist relevant, dazu komme ich noch.

Die Ursache liegt in der Datenbankabstraktions-API, die Drupal Core zur Validierung von Abfragen und zur Absicherung gegen SQL-Injection verwendet. Eine speziell präparierte Anfrage kann diese Absicherung umgehen und beliebige SQL-Injection ermöglichen – jedoch ausschließlich bei Sites, die PostgreSQL nutzen. MySQL- und MariaDB-Deployments sind laut Drupals eigenem Advisory nicht betroffen. Der Angriffspfad reicht von Informationsoffenlegung über Privilege Escalation bis hin zu Remote-Code-Ausführung in bestimmten Fällen. Entscheidend: Der Angriff erfordert keine Authentifizierung. Anonyme Nutzer aus dem öffentlichen Internet können ihn versuchen.

Korrigierte Releases sind für alle unterstützten Branches verfügbar: Drupal 11.3.10, 11.2.12, 11.1.10, 10.6.9, 10.5.10 und 10.4.10. Die unterstützten Branches (11.3, 11.2, 10.6 und 10.5) enthalten außerdem vorgelagerte Sicherheitsupdates für Symfony und Twig – das bedeutet, der Patch ist kein Einzel-Datei-Tausch, sondern ein Abhängigkeits-Update. Drupal 7 ist nicht betroffen. Drupal 8 und Drupal 9 haben ihren End-of-Life erreicht, aber angesichts der Schwere der Lücke hat das Projekt manuelle Patches für 9.5 und 8.9 als „Best Effort" bereitgestellt. Drupal 11.1.x, 11.0.x, 10.4.x und älter befinden sich außerhalb des Versorgungsbereichs. Den CVE-Eintrag für das kanonische Advisory-Tracking finden Sie direkt beim zuständigen Verzeichnis.

Technische Analyse

Der Mechanismus verdient Aufmerksamkeit, weil er erklärt, warum CVSS-Score und die Schwerebewertung des Projekts auseinanderfallen. Drupals Datenbankabstraktionsschicht existiert genau deshalb, damit Anwendungsentwickler kein handgeschriebenes SQL je nach Backend benötigen. Die Schicht normalisiert Parameter-Binding, Quoting und Identifier-Escaping über MySQL, PostgreSQL und SQLite hinweg. Wenn die Abstraktion selbst bei einem Backend versagt, erbt jedes darauf aufsetzende Modul die Schwachstelle – selbst Module, deren Autoren alles richtig gemacht haben. Das ist der strukturelle Grund, warum ein einziger Core-CVE über Tausende von Contrib-Modulen kaskadieren kann, ohne dass eines dieser Module individuell angreifbar ist.

Der ausschließlich auf PostgreSQL begrenzte Wirkungsbereich deutet auf ein backendspezifisches Quoting- oder Type-Coercion-Verhalten im Treiber hin. PostgreSQL behandelt bestimmte Bezeichner- und String-Literal-Randfälle anders als MySQL – insbesondere bei Groß-/Kleinschreibung, Dollar-Quoting und Array-Syntax. Ein Sanitizer, der MySQL-Semantik voraussetzt, wird bei Postgres undicht. Drupal veröffentlicht keine Exploit-Details, und das ist richtig so, aber die Struktur des Fehlers ist konsistent mit einem Treiberschicht-Mismatch und nicht mit einem Logikfehler in einem bestimmten Modul.

Der Eskalationspfad von SQL-Injection zu RCE in Drupal ist bekannt. Sobald ein Angreifer beliebige Zeilen schreiben kann, sind die Cache-Tabellen, die Session-Tabelle und die Konfigurationstabellen, die serialisierte PHP-Objekte speichern, die Angriffsziele. Eine präparierte serialisierte Payload einschleusen, eine Deserialisierung beim nächsten Request auslösen – und Code-Ausführung unter dem Webserver-Nutzer ist möglich. Das entspricht den MITRE ATT&CK-Techniken rund um die Ausnutzung öffentlich zugänglicher Anwendungen und serverseitige Deserialisierung. Der CVSS-Wert von 6,5 spiegelt wahrscheinlich den bedingten Charakter des RCE-Pfads wider (nicht alle Sites haben beschreibbare Konfigurationstabellen, die der Cache-Schicht ausgesetzt sind), aber für einen CFO, der Rückstellungen für Vorfälle genehmigt, zählt das Worst-Case-Szenario – nicht der Medianwert.

Die Symfony- und Twig-Updates, die in den Releases der unterstützten Branches enthalten sind, fügen eine zweite Komplexität hinzu. Teams, die nur die Drupal-Core-Dateien patchen und das Vendor-Directory-Refresh überspringen, werden glauben, abgesichert zu sein – ohne es zu sein.

Wer Betroffen Ist

Die exponierte Gruppe ist enger als bei einem typischen Drupal-Core-CVE, aber die Konzentration ist gravierend. Drupal-on-PostgreSQL ist nicht der Standard-Stack. Er tritt gehäuft an drei Stellen auf: im europäischen öffentlichen Sektor und bei Behörden, wo Postgres vorgeschrieben ist; bei Hochschulportalen, die Postgres aus einem breiteren institutionellen Standard übernommen haben; und in regulierten Branchen (Versicherungen, Gesundheitswesen, bestimmte Fintech-Bereiche), wo das Platform-Team Postgres wegen JSONB oder aus Lizenzgründen gewählt hat. Das sind genau die Betreiber mit den langsamsten Change-Management-Zyklen und dem höchsten Compliance-Aufwand pro Deployment.

Die Frage, die der CFO diese Woche stellen muss – und die der Rechtsberater als erstes stellen wird – lautet: Betreiben wir Drupal auf Postgres irgendwo in unserem Bestand, und wenn ja, wie lange haben wir Zeit für Datenschutzmeldungen, falls wir nicht ausschließen können, bereits kompromittiert worden zu sein? Die Ausnutzbarkeit durch anonyme Nutzer bedeutet, dass es keine Authentifizierungsprotokolle zum Durchsuchen gibt. Die Erkennung liegt in WAF-Telemetrie und Datenbankabfrageprotokollen, die die meisten mittelständischen Drupal-Betreiber nicht in der für retrospektive Forensik erforderlichen Granularität vorhalten.

Besonders stark betroffen ist, wer noch auf Drupal 8, 9 oder den End-of-Life-10.x-Branches läuft. Die „Best Effort"-Patches für 8.9 und 9.5 sind eine Gefälligkeit, keine Verpflichtung. Drupal hat explizit darauf hingewiesen, dass diese Versionen weiterhin andere, bereits früher bekannt gewordene Schwachstellen aufweisen. Wer im Jahr 2026 auf 8.9 läuft, hat mit diesem CVE nur ein Symptom – nicht die eigentliche Ursache. Das eigentliche Problem ist, dass das Platform-Team ein Major-Version-Upgrade so lange aufgeschoben hat, dass das Aufschieben teurer ist als das Angriffsrisiko.

Auf dem Arbeitsmarkt ist mit einem kurzen Nachfrageschub nach Drupal-Upgrade-Spezialisten zu rechnen – ähnlich wie das Magento-1-EOL einen Mini-Boom für Auftragnehmer ausgelöst hat. Das Angebot ist dünn. Erfahrene Drupal-Entwickler sind seit drei Jahren still in Richtung Headless- und JAMstack-Rollen abgewandert.

Leitfaden für Sicherheitsteams

Beginnen Sie mit der Inventarisierung, nicht mit dem Patching. Man kann nicht patchen, was man nicht als betrieben kennt. Ziehen Sie jeden Drupal-Hostnamen aus Ihrem Asset-Management, ermitteln Sie das Datenbank-Backend (Postgres vs. MySQL) und markieren Sie die Postgres-Gruppe als Priorität eins. Für die MySQL-Gruppe sollte ebenfalls gepatcht werden, aber die Dringlichkeit sinkt, weil dieser spezifische CVE dort nicht greift.

Für Postgres-basierte Sites auf einem unterstützten Branch: Aktualisieren Sie auf 11.3.10, 11.2.12, 10.6.9 oder 10.5.10 je nach Ihrer Linie. Aktualisieren Sie das Vendor-Directory: Die Symfony- und Twig-Updates werden nicht zufällig im selben Release ausgeliefert. Führen Sie Smoke-Tests in der Staging-Umgebung für Ihre meistbesuchten Content-Typen und alle Custom-Module durch, die db_query oder die Entity-Query-API berühren.

Für Postgres-basierte Sites auf 11.1.x, 11.0.x, 10.4.x oder älter gibt es zwei Wege: Entweder wechseln Sie in diesem Quartal zu einem unterstützten Branch, oder Sie akzeptieren, dass Sie nicht unterstützte Infrastruktur betreiben, und kalkulieren das Risiko entsprechend ein. Für 9.5 und 8.9 wenden Sie die manuellen Patches als Überbrückungsmaßnahme an, behandeln Sie sie jedoch als Lebenserhaltung – nicht als Lösung. Alles, was noch auf Drupal 7 läuft, ist von diesem CVE nicht betroffen, befindet sich aber selbst im EOL-Status und hat sein eigenes Portfolio ungelöster Probleme.

Auf der Erkennungsseite: Instrumentieren Sie Ihre WAF für anomale Query-Strings, die Drupal-Endpunkte treffen, protokollieren Sie alle 500er-Fehler von PHP, und ziehen Sie jetzt eine Baseline der Datenbankabfragemuster, damit Sie bei späteren Kompromittierungsindikatoren einen Vergleichswert haben. Prüfen Sie den CISA KEV-Katalog die nächsten zwei Wochen täglich. Sollte dieser CVE dort auftauchen, treffen Bundesauftragnehmer harte Fristen für die Behebung – unabhängig von internen Change-Windows.

Der Head of Platform sollte diese Woche beim VP Engineering nachfragen, ob der Drupal-Bestand auf einem Sunset-Fahrplan mit einem datierten Endpunkt liegt oder ob er driftet, weil niemand die Entscheidung verantwortet. Dieses Gespräch ist unabhängig von CVE-2026-9082 längst überfällig, und der Patch-Zyklus ist ein willkommener Anlass, es auf die Agenda zu bringen.

Wichtigste Erkenntnisse

• CVE-2026-9082 ist eine durch anonyme Nutzer ausnutzbare SQL-Injection in der Datenbankabstraktions-API von Drupal Core, mit einem Pfad zu RCE ausschließlich auf PostgreSQL-basierten Sites.
• Korrigierte Versionen sind Drupal 11.3.10, 11.2.12, 11.1.10, 10.6.9, 10.5.10 und 10.4.10; die Releases der unterstützten Branches enthalten auch Symfony- und Twig-Updates, die gemeinsam eingespielt werden müssen.
• Drupal 8.9 und 9.5 erhalten trotz EOL manuelle Best-Effort-Patches; ältere 10.x- und 11.x-Punktversionen erhalten nichts.
• Der CVSS-Wert von 6,5 unterschätzt den operativen Schweregrad, weil er über bedingte Eskalationspfade gemittelt wird; behandeln Sie anonym erreichbare SQL-Injection als Vorfall mit höchster Priorität.
• Teams, die Drupal im Jahr 2026 als strategische Plattform evaluieren, sollten jetzt fragen, ob die Betriebskosten eines selbst gehosteten PHP-CMS noch die Migrationskosten zu einer verwalteten oder Headless-Alternative überwiegen.