Skip to content

Injection SQL critique dans trilogy (Rails) via l'échappement multi-octets

Une injection SQL critique (CVSS 9.3) dans Trilogy#escape touche les applications Rails utilisant l'adaptateur trilogy. Corrigée en 2.13.2. Pas de CVE, référence GHSA-744p-w4gc-m3gh.

Publié le 3 min de lecture

Le mainteneur de trilogy, le client MySQL que Rails propose comme adaptateur de base de données, a publié le 29 octobre un avis GHSA-744p-w4gc-m3gh : une injection SQL critique, CVSS 9.3, dans la fonction d'échappement de la bibliothèque. Le CERT-FR a relayé le même jour via l'avis CERTFR-2026-AVI-1424. La correction est en 2.13.2 ; toutes les versions ≤ 2.13.1 sont concernées.

Ce que fait la faille

Trilogy#escape produit une sortie non sûre pour les chaînes encodées en Shift_JIS, Windows-31J, Big5, GBK ou GB18030. Dans ces encodages, l'octet de continuation d'un caractère multi-octets peut tomber dans la plage ASCII. La fonction d'échappement, écrite pour des sur-ensembles stricts d'ASCII, ne gérait pas ce cas : un guillemet injecté via un tel octet n'était pas neutralisé, ce qui ouvre la porte à une injection SQL.

L'avis décrit deux cas d'exposition :

  • N'importe quel jeu de caractères de connexion, y compris le utf8mb4 par défaut, dès lors qu'un attaquant peut influencer l'encodage d'une chaîne passée à la requête.
  • Les connexions configurées avec les encodages hérités concernés, qui lèvent désormais une ArgumentError après correctif.

Le vecteur CVSS v4 publié est AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N : exploitable à distance, sans authentification ni interaction, avec impact élevé sur la confidentialité et l'intégrité des données.

Pas de CVE, mais une origine notable

L'avis le précise : aucun CVE n'est attribué, la référence à citer est le GHSA. La faille a été remontée par Mike Dalessio (flavorjones) et découverte par le scanner de code open source d'Anthropic (identifiant interne ANT-2026-9KOHJMNW). Le bulletin Rails reprend les mêmes détails.

Que faire

  1. Mettez trilogy à jour en 2.13.2. C'est le seul correctif ; il n'y a pas de contournement propre côté application.
  2. Identifiez vos adaptateurs. Repérez les applications Rails qui utilisent l'adaptateur trilogy (et non mysql2) pour MySQL — ce sont elles qui embarquent la bibliothèque vulnérable.
  3. Auditez les chemins où l'encodage d'une chaîne vient d'une entrée utilisateur. C'est le cas d'exposition le plus large, puisqu'il touche même les connexions en utf8mb4.
  4. Surveillez les connexions en encodages hérités. Après le correctif, elles lèvent une ArgumentError : un pic d'erreurs peut signaler du code qui s'appuyait sur le comportement vulnérable.

Contexte

L'échappement manuel de requêtes est un classique des régressions d'injection SQL : il suffit d'un cas d'encodage non prévu pour que la neutralisation saute. Le point qui distingue cet avis, c'est la découverte par un scanner automatisé — même logique que les campagnes de recherche de vulnérabilités assistées par modèle dont la rédaction suit les résultats. Un CVSS de 9.3 sans numéro CVE reste une faille critique : traitez l'absence de CVE comme un détail administratif, pas comme une atténuation.

Articles liés