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.
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
utf8mb4par 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
ArgumentErroraprè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
- Mettez trilogy à jour en 2.13.2. C'est le seul correctif ; il n'y a pas de contournement propre côté application.
- Identifiez vos adaptateurs. Repérez les applications Rails qui utilisent l'adaptateur
trilogy(et nonmysql2) pour MySQL — ce sont elles qui embarquent la bibliothèque vulnérable. - 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. - 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.