Библиотека Trilogy содержит уязвимость внедрения SQL-кода. Trilogy - драйвер базы данных MySQL для приложений на Ruby, его использует адаптер Active Record в Rails. Адаптер здесь - прослойка, которая связывает код приложения с конкретной базой данных. Проблема в функции экранирования строк: на некоторых кодировках она возвращает небезопасный результат, и строка из внешнего ввода выполняется как часть SQL-запроса.
Оценка Critical и условия атаки на Trilogy
Уведомление относит проблему к уровню Critical, хотя балл издатель не приводит. По вектору CVSS v4 атака идёт по сети, сложность низкая, учётные данные не нужны, участие пользователя не требуется. Следовательно, внедрение SQL-кода остаётся неаутентифицированным. Сведений об эксплуатации в реальных атаках в уведомлении нет, а идентификатора CVE пока нет: автор отчёта обещает обновить запись, когда номер появится.
По оценке сопровождающего библиотеки, уязвимыми с большой вероятностью окажутся приложения на Rails и другие приложения на Ruby, которые работают через интерфейс Rack и используют Trilogy как адаптер MySQL. Rack - общий интерфейс между веб-сервером и таким приложением. Обновляться автор отчёта советует немедленно. Точного перечня затронутых продуктов в бюллетене Ruby on Rails 91797 от 29 октября 2026 года нет, поэтому вывод остаётся предварительным.
Экранирование нужно, чтобы подставлять в SQL-запрос пользовательские строки без риска. Вместо спецсимволов в строке появляются безопасные последовательности, и кавычка перестаёт быть частью инструкции. В однобайтовых кодировках каждый байт обозначает отдельный символ, поэтому замена работает предсказуемо. В многобайтовых символ занимает несколько байтов, и функция должна отличать начало символа от его продолжения.
Функция в Trilogy рассчитана на кодировки, где многобайтовые символы не содержат байтов из диапазона ASCII. В Shift_JIS, Windows-31J, Big5, GBK и GB18030 это условие не выполняется: второй байт символа может попасть в диапазон ASCII. Из-за этого атакующий прячет кавычку внутри многобайтового символа, и экранирование пропускает её. Кодировка utf8mb4, принятая в Rails по умолчанию, в этот перечень не входит, поэтому сама по себе она уязвимость не создаёт.
Уязвимость проявляется в двух случаях. Первый - любая кодировка соединения, включая utf8mb4 по умолчанию, если атакующий может влиять на кодировку строки, которую экранирует приложение. Второй - соединения с кодировкой sjis, cp932, big5, gbk или gb18030: они никогда не работали корректно, их больше не поддерживают, и теперь они вызывают ошибку аргумента.
По вектору последствия касаются конфиденциальности и целостности данных, а влияния на доступность издатель не заявляет. Значит, атакующий может читать и изменять записи в базе, но не останавливать её работу. Это следует из метрик вектора, отдельных пояснений в уведомлении нет.
Исправление вышло в версии 2.13.2. Уязвимы все версии Trilogy до 2.13.1 включительно, так что обновление закрывает проблему целиком. Тем, кто не может обновиться сразу, издатель предлагает принудительно приводить к явной кодировке все строки, которые приложение передаёт в функции экранирования и выполнения запросов Trilogy. Такой обход не устраняет ошибку, а только снижает вероятность её срабатывания.
Бюллетень 91797 от 29 октября 2026 года номера исправленной версии не приводит и отсылает к уведомлению разработчика. Там разработчик называет исправленной версию 2.13.2.
Номер уведомления на GitHub - GHSA-744p-w4gc-m3gh. Уязвимость нашёл сканер открытого кода Anthropic OSS Scanner, во внутренней нумерации - ANT-2026-9KOHJMNW. Автор готовил отчёт с помощью ИИ. Публикация механизма атаки не означает, что уязвимость уже используют: таких данных нет.
Внедрение SQL-кода в драйвере базы данных срабатывает ниже уровня приложения, где проверки ввода уже не действуют. Патч доступен, поэтому основная задача - сверить версию Trilogy в списке зависимостей приложения и обновить её. Идентификатор CVE и данные об атаках могут появиться позже, тогда уведомление обновят.
Ссылки
- https://github.com/trilogy-libraries/trilogy/security/advisories/GHSA-744p-w4gc-m3gh
- https://discuss.rubyonrails.org/t/ghsa-744p-w4gc-m3gh-sql-injection-through-trilogy-escape-with-multibyte-encodings/91797
