Критична уразливість CVE-2026-42208 у популярному open source AI‑шлюзі LiteLLM уже використовується в реальних атаках. Менш ніж за півтори доби після публічного розкриття технічних деталей зловмисники почали цілеспрямовано добувати з інстансів LiteLLM конфіденційні дані та API‑ключі постачальників великих мовних моделей.
Критична уразливість LiteLLM CVE-2026-42208: суть та масштаб проблеми
Уразливість CVE-2026-42208 класифікована як SQL‑інʼєкція з базовим балом CVSS 9.3. Помилка реалізації механізму перевірки проксі‑ключів призвела до того, що значення користувацького API‑ключа підставлялося безпосередньо в текст SQL‑запиту, а не передавалося як параметризований аргумент.
За оцінкою розробників, неавторизований атакувальний клієнт міг надіслати спеціально сформований заголовок Authorization до будь‑якого LLM‑маршруту (наприклад, POST /chat/completions) і через гілку обробки помилок досягти вразливого SQL‑запиту. Це відкривало можливість як для читання вмісту бази даних, так і для зміни записів, що фактично означає несанкціонований контроль над проксі та його секретами.
Проблема стосується усіх релізів LiteLLM до версії 1.83.7-stable, де 19 квітня 2026 року було застосовано виправлення. Точний перелік затронутих версій наведено в офіційній консультації GitHub Security Advisory GHSA-r75f-5x8p-qvmc.
Як SQL-інʼєкція проявляється в AI‑шлюзі LiteLLM
SQL‑інʼєкція — один із найстаріших і водночас найефективніших класів атак, коли неочищені користувацькі дані дозволяють виконати довільний SQL‑код у контексті застосунку. У випадку LiteLLM критичною точкою стала підсистема логування та обробки помилок, де API‑ключ із заголовка Authorization опинявся вбудованим у SQL‑вираз.
Керуючи цим значенням, зловмисник міг змінювати структуру запиту до бази даних: змушувати її повертати додаткові стовпці, читати інші таблиці або навіть виконувати модифікуючі операції. Важливо, що все це відбувалося до проходження аутентифікації, тому будь‑який публічно доступний екземпляр LiteLLM ставав привабливою мішенню для автоматизованих сканерів та цілеспрямованих атак.
Експлуатація CVE-2026-42208: таймлайн атак і поведінка зловмисників
За даними компанії Sysdig, перша зафіксована спроба експлуатації CVE-2026-42208 відбулася 26 квітня 2026 року о 16:17 UTC — приблизно через 26 годин після індексування консультації GHSA у GitHub Advisory Database і менш ніж через 36 годин після публікації уразливості.
Початкові запити надходили з IP‑адреси 65.111.27[.]132. Дослідники описують атаку як двоетапну: спочатку здійснювалася серія SQL‑інʼєкційних запитів з одного egress‑адреса, а через близько 20 хвилин зловмисник перейшов на IP 65.111.25[.]67, продовживши зондування та додавши неавторизовані звернення до endpoint‑ів управління ключами.
Основними цілями стали таблиці litellm_credentials.credential_values та litellm_config, де зберігаються ключі LLM‑провайдерів і параметри виконання проксі. Доступів до litellm_users та litellm_team не зафіксовано, що вказує на добре розуміння схеми БД і прицільне полювання саме за секретами, а не за обліковими записами.
Чому компрометація бази LiteLLM настільки небезпечна
LiteLLM — один із найпопулярніших open source AI gateway із понад 45 000 зірок та 7 600 форків на GitHub. Його завдання — виступати єдиною точкою доступу до різних LLM‑провайдерів і централізовано керувати їхніми ключами та політиками доступу.
На практиці це означає, що один рядок у litellm_credentials може одночасно містити, наприклад, організаційний ключ OpenAI з лімітами витрат у п’ятизначному діапазоні, консольний ключ Anthropic з правами адміністратора робочого простору та облікові дані AWS Bedrock IAM. За оцінками Sysdig, успішне витікання такої бази за масштабом ризику наближається до повної компрометації хмарного акаунта, а не до типової для web‑додатків SQL‑інʼєкції.
Додатковий контекст посилює ризики: менш ніж за місяць до цього LiteLLM уже став об’єктом атаки на ланцюг постачання (supply chain attack) з боку угруповання TeamPCP, спрямованої на викрадення секретів у downstream‑користувачів. Сукупність інцидентів показує, що AI‑інфраструктура стає пріоритетною ціллю для кіберзлочинців.
Як захистити LiteLLM та AI‑інфраструктуру: практичні кроки
Адміністраторам та DevOps‑командам, які експлуатують LiteLLM у продакшені, варто діяти без зволікань. Базовий крок — оновлення до версії 1.83.7-stable або новішої, де уразливість CVE-2026-42208 усунено.
Тимчасовий обхідний шлях та додаткові заходи безпеки
Якщо негайне оновлення неможливе, розробники пропонують тимчасовий варіант: у конфігурації LiteLLM в блоці general_settings встановити disable_error_logs: true. Це відключає вразливий шлях обробки помилок, через який дані із заголовка потрапляли в SQL. Однак така міра має розглядатися виключно як короткостроковий захід, оскільки знижує спостережуваність системи і не усуває кореневу причину в коді.
Додатково рекомендується:
- проаналізувати журнали LiteLLM на предмет підозрілих
Authorization‑заголовків, спроб SQL‑інʼєкції та аномальних запитів до LLM‑endpoint‑ів; - виконати повну ротацію всіх API‑ключів і облікових даних, що зберігалися в LiteLLM (OpenAI, Anthropic, AWS Bedrock тощо);
- обмежити мережевий доступ до LiteLLM‑проксі (списки дозволених IP, VPN, підходи Zero Trust для AI‑сервісів);
- запровадити регулярне SAST/DAST‑тестування та перевірки безпеки саме для компонентів AI‑інфраструктури, а не лише для класичних веб‑додатків;
- використовувати централізовані сховища секретів та мінімізувати обсяг критичних ключів, що зберігаються в єдиній таблиці.
Інцидент GHSA-r75f-5x8p-qvmc демонструє нову реальність: для критичних уразливостей в AI‑шлюзах вікно між розкриттям і першою реальною експлуатацією вимірюється годинами, а не тижнями. Зловмисникам часто достатньо тексту консультації та опису схеми БД, без публічного exploit‑коду. Організаціям, що активно інтегрують LLM та AI gateway‑рішення, варто вже зараз переглянути моделі загроз, процеси оновлення, моніторинг і управління секретами так, ніби кожен публічний advisory буде використано практично миттєво. Це один із ключових кроків до зрілої кібербезпеки AI‑інфраструктури.
