Drupal corrige une injection SQL critique (CVE-2026-9082) — exploitée dans les 48 h

Drupal a publié un avis d’urgence pour CVE-2026-9082 le 18 mai, puis relevé le score de risque quatre jours plus tard quand l’exploitation active a démarré. La faille est une injection SQL non authentifiée dans l’API d’abstraction base de données de Drupal core, notée 23/25 — Hautement critique sur l’échelle Drupal.

Bonne nouvelle relative : seuls les sites adossés à PostgreSQL sont exploitables. Les installations MySQL, MariaDB et SQLite ne sont pas touchées.

Versions concernées

Une longue série de branches doit être patchée :

• >= 8.9.0 < 10.4.10
• >= 10.5.0 < 10.5.10
• >= 10.6.0 < 10.6.9
• >= 11.0.0 < 11.1.10
• >= 11.2.0 < 11.2.12
• >= 11.3.0 < 11.3.10

Correctifs : 10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12, 11.3.10. Appliquez le patch correspondant à votre branche — Drupal ne backporte pas au-delà.

Ce que fait la faille

La couche d’abstraction base de données de Drupal est censée assainir les valeurs injectées dans les requêtes. CVE-2026-9082 permet à une requête forgée d’atteindre le handler EntityQuery PostgreSQL avec des clés de tableau non assainies, qui glissent telles quelles dans la chaîne SQL. À partir de là, un attaquant non authentifié peut lire ou modifier tout ce à quoi l’utilisateur base de données de Drupal a accès — c’est-à-dire, dans une installation typique, tout.

L’avis Drupal le formule sobrement : impact confidentialité « toutes les données non publiques accessibles », impact intégrité « toutes les données modifiables ou supprimables ». Dans bon nombre de configurations, la faille chaîne vers une RCE via COPY ... FROM PROGRAM si le rôle PostgreSQL est superuser — une mauvaise pratique trop répandue.

La vulnérabilité a été remontée par Michael Maturi, de l’équipe Mandiant chez Google.

Statut de l’exploitation

Drupal a mis à jour l’avis le 22 mai pour confirmer des tentatives d’exploitation in the wild. Dans les 48 premières heures, plusieurs éditeurs ont rapporté des scans massifs sur des milliers de sites dans plus de 65 pays — du balayage automatisé, opportuniste plus que ciblé.

Que faire aujourd’hui

1. Patcher. Dans la journée si vous tournez sur PostgreSQL. Dans la semaine sinon, parce qu’une régression future peut changer la donne.
2. Vérifier votre moteur. Lisez settings.php et regardez le driver — pgsql veut dire que vous êtes exposé ; mysql, mariadb ou sqlite non.
3. Auditer le rôle PostgreSQL. Si Drupal se connecte en superuser, rétrogradez-le. Le principe de moindre privilège transforme une SQLi catastrophique en SQLi contenue.
4. Chasser les indicateurs. Comptes admin inattendus, entrées modifiées dans users_field_data, nœuds de contenu inexplicables. Inspectez les logs HTTP de la semaine sur /jsonapi/, /views/ajax et les endpoints de formulaires.
5. Planifier la rotation. Tout site compromis doit être traité comme un événement de fuite d’identifiants — rotation des clés, sessions, jetons API accessibles depuis Drupal.

La CVE-2026-9082 ne figurait pas encore au catalogue KEV de la CISA à l’heure de publication, mais elle y entrera probablement sous quelques jours.