Уязвимости в Spring AI и ONNX: как дыры в ИИ‑фреймворках превращаются в утечки данных и чужие модели

TL;DR

• В марте нашли критичные уязвимости в Spring AI и ONNX.

• В Spring AI всплыли SQL‑инъекции и JSONPath‑инъекции в сценариях работы с БД и данными.

• В ONNX можно обойти проверку доверия при загрузке моделей через onnx.hub.load.

• Для ИТ,ИБ это сигнал не только «пропатчить», а навести порядок в ИИ‑стеке: инвентаризация, правила для ИИ‑проектов, отдельный контур безопасности.

Уязвимости в Spring AI и ONNX: как дыры в ИИ‑фреймворках превращаются в утечки данных и чужие модели

Вместо длинной преамбулы

ИИ‑фреймворки привыкли воспринимать как что‑то «про математику».
Где‑то внутри крутятся модели, рядом лежат .onnx‑файлы, а сверху над этим аккуратный API.

В реальных системах всё веселее.
Весной в обзорах уязвимостей сразу всплыли критичные баги в Spring AI и ONNX: SQL‑инъекции, JSONPath‑инъекции и обход проверки доверия при загрузке моделей.
То есть классика старого доброго веба тихо переезжает в слой ИИ, который во многих компаниях живёт в режиме пилотов и «у нас там ничего критичного».

Если вы отвечаете за ИТ, ИБ или цифровую трансформацию, это хороший момент взглянуть на свои ИИ‑проекты не как на игрушки, а как на нормальные боевые системы.

Что нашли в Spring AI и ONNX, по‑человечески

Без ныряния в каждую CVE по строчке, соберём общую картинку.

Spring AI

Spring AI помогает прикрутить LLM и прочие модели к приложениям на базе Spring.
Под капотом у него есть работа с базами и данными. В свежих уязвимостях всплыли:

• SQL‑инъекция в сценариях, где Spring AI ходит в базу (например, через интеграцию с MariaDB). Можно подмешать свой SQL и вытащить лишнего.

• JSONPath‑инъекция: если выражение собирают из пользовательского ввода без нормальной фильтрации, появляется возможность читать или править чужие данные в ИИ‑приложении.

Переводим на нормальный язык: рискуют логи запросов, истории диалогов, результат генераций, профили пользователей и всё, что живёт рядом с этим функционалом. Плюс многопользовательские системы, где один клиент может подсмотреть данные другого.

ONNX

ONNX — это про формат моделей и удобную загрузку через onnx.hub.load и подобные штуки.
В одной из свежих дыр оказалось, что проверку доверия при загрузке модели можно обойти и подсунуть не тот артефакт, на который вы рассчитывали.

Дальше всё зависит от вашей архитектуры:

• где‑то это «просто» подмена модели (другая логика, другие веса, странное поведение сервиса),

• где‑то начинается веселье посерьёзнее: в цепочке вокруг модели могут быть конвертеры и обработчики, в которых при удачном стечении обстоятельств возможен уже и RCE.

В итоге у нас два симптома:
Spring AI показывает, что ИИ‑обвязка может дырявить данные,
ONNX напоминает, что модели — такой же поставляемый артефакт, как бинарь или контейнер.

Где такие штуки обычно прячутся в компании

Часто на вопрос «у нас Spring AI или ONNX есть?» ответ звучит примерно так: «ну, наверное, где‑то у разработчиков, но в прод это точно не попадало».

Раскопки обычно показывают другое.

Spring AI чаще всего всплывает в:

• внутренних ассистентах для сотрудников (поиск по документам, помощь в заявках, подсказки в CRM);

• экспериментальных сервисах, которые тихо доросли до критичных: начинали как прототип «для двух отделов», а теперь на них опирается половина компании;

• интеграциях между классическим Spring‑приложением и внешними/внутренними LLM.

ONNX встречается в:

• рекомендательных и скоринговых сервисах, которые никто не трогал годами, но они продолжают крутиться в проде;

• пайплайнах MLOps, где команда данных использует ONNX как общий язык между разными фреймворками;

• покупных продуктах, где ONNX живёт внутри, а снаружи вы видите просто «коробочное решение» с красивым интерфейсом.

То есть не обязательно вы лично «разрешали» Spring AI и ONNX.
Решение могло родиться в ML‑команде, у интеграторов или у вендора.
В проде при этом всё уже работает и трогать страшно.

Почему это история не только для CISO

С точки зрения ИБ классический план понятен: найти, пропатчить, закрыть риски.
Но для CDTO/CTO здесь есть более широкий пласт задач.

1. Выделить ИИ‑инфраструктуру в отдельный объект

Пока ИИ‑фреймворки лежат в одной куче с «прочими библиотеками», они всегда проигрывают в приоритете.
Нужна отдельная полка в архитектуре и регламентах: Spring AI, ONNX, LLM‑шлюзы, хабы моделей и подобные вещи.

Простой эффект:

• появляется отдельная зона ответственности,

• появляются явные правила,

• НКО и «быстрые пилоты» не пролетают мимо стандартов только потому, что это ИИ и «мы тут экспериментируем».

2. Провести инвентаризацию ИИ‑стека, а не «поймать конкретную CVE»

Список «где у нас Spring AI и ONNX» — полезная штука, но этого мало.
Нужен нормальный каталог:

• какие ИИ‑фреймворки и хабы используются;

• кто владелец каждой штуки (команда, человек, роль);

• какие данные через них проходят;

• где они стоят: прод, тест, песочница, пилот.

Без этого любая новая уязвимость превращается в квест «пойди туда, не знаю куда».

3. Переключить режим для ИИ‑проектов

Пока ИИ‑инициативы живут в режиме «сначала покажем value, потом будем думать про безопасность», ИБ и архитектура всегда будут подключаться в последний момент.

Удобный рубеж: как только ИИ‑сервис полез в реальные данные клиентов или сотрудников, он переезжает в ту же лигу, что CRM, биллинг и прочие взрослые системы.
Со всеми вытекающими: требования, ревью, мониторинг, патчи.

4. Поменять взаимодействие CDTO/CTO — CISO — ML/Dev

Сейчас выбор фреймворков часто принимает команда разработки или ML, а безопасность подключается затем, когда «уже всё работает, не ломайте».

Задача на управленческом уровне — договориться:

• какие ИИ‑компоненты считаются стратегическими (Spring AI, ONNX, прокси к LLM, реестры моделей);

• кто их согласует;

• по каким минимальным требованиям (обновляемость, политика CVE, логирование, возможность ограничить права и т.п.) их пропускают в прод.

Чек‑лист по Spring AI и ONNX «на неделю»

Если хочется что‑то сделать, можно взять минимальный план.

Spring AI

• Найти проекты, где он используется: по зависимостям, по репозиториям, через короткий опрос ключевых команд.

• Для каждого проекта ответить на два вопроса:

  • какие данные доступны через этот сервис (БД, логи, файловые хранилища, внешние API);

  • есть ли там многопользовательский сценарий (один клиент/подразделение может случайно увидеть данные другого).

• Запланировать обновление Spring AI до версий с закрытыми уязвимостями. Если обновить «здесь и сейчас» страшно, хотя бы выделить ответственных и дедлайны.

• Добавить в автотесты базовые проверки на инъекции (SQL и JSONPath) для сервисов, где есть взаимодействие с данными через Spring AI.

ONNX

• Найти все места, где:

  • используется onnx.hub.load или похожая логика загрузки моделей;

  • есть автоматическое обновление моделей «из облака» или из хаба.

• Ограничить источники моделей:

  • завести белый список репозиториев и допустимых моделей;

  • отключить автоматическую загрузку из неизвестных мест.

• Для решений от вендоров:

  • запросить у них позицию по уязвимости и план обновлений;

  • задать прямые вопросы про валидацию моделей и логи операций.

Процессы

• Добавить ИИ‑фреймворки и хабы в общий перечень критичных компонентов, за которыми следят при появлении новых уязвимостей.

• Назначить конкретного человека/роль, которая отвечает за мониторинг уязвимостей именно в ИИ‑стеке, чтобы это не терялось между ОС и веб‑сервисами.

• Описать минимальные требования к ИИ‑проектам в документах: архитектурных принципах, стандартах по ИБ и DevSecOps.

Вместо вывода

Первые ИИ‑кейсы живут на энтузиазме: «сделали ассистента, всем понравилось, поехали дальше».
Через пару лет к этому добавляются более приземлённые истории: утечки, уязвимости, вопросы регуляторов.

Spring AI и ONNX в мартовских выпусках по безопасности — хороший маркер, что ИИ‑слой дорос до нормальной взрослой жизни.
Разница только в том, что под этим слоем теперь проходят логины клиентов, договоры, чаты сотрудников и всё, что раньше аккуратно лежало по разным системам.

Лучший момент привести ИИ‑инфраструктуру в чувство — пока на неё ещё не прилетел свой большой публичный инцидент.
Заодно это хороший способ показать бизнесу, что ИИ в компании — не только про красивые демо, но и про внятную инженерную и управленческую работу.