Як уразливості LangGraph дозволяють довести SQL injection до RCE

Дослідники Check Point розкрили три виправлені вразливості в LangGraph — відкритому фреймворку LangChain для створення багатoагентних ІІ-застосунків. Дві з них, за даними дослідників, поєднуються в ланцюжок експлуатації, що призводить до віддаленого виконання коду (RCE) на серверах із самостійним розгортанням. Вразливості зачіпають компоненти зберігання контрольних точок (checkpointer) для SQLite і Redis. Керована платформа LangSmith, як повідомляється, не схильна до цих проблем. Користувачам самостійно розгорнутих інсталяцій необхідно негайно оновити уражені пакети.

Виявлені вразливості

Усі три вразливості виявлені дослідником Ярденом Поратом із Check Point і задокументовані в технічному звіті компанії. Кожна з них отримала окремий ідентифікатор CVE та підтверджена в рекомендаціях GitHub Security Advisory:

• CVE-2025-67644 (CVSS 7.3) — SQL injection у реалізації контрольних точок SQLite. Зловмисник може маніпулювати SQL-запитами через ключі фільтрів метаданих. Уражені версії langgraph-checkpoint-sqlite до 3.0.1.
• CVE-2026-28277 (CVSS 6.8) — небезпечна десеріалізація msgpack у LangGraph, що дає змогу ініціювати реконструкцію об’єктів під час завантаження контрольної точки зі зміненими даними. Уражені версії langgraph до 1.0.10.
• CVE-2026-27022 (CVSS 6.5) — ін’єкція запитів RediSearch у @langchain/langgraph-checkpoint-redis, що дозволяє обійти механізми контролю доступу. Уражені версії до 1.0.1.

Варто зазначити, що жодна з вразливостей окремо не досягає критичного рівня за шкалою CVSS. Однак саме їхня комбінація створює найсерйознішу загрозу.

Механізм ланцюжка експлуатації: від SQL injection до RCE

За даними Check Point, CVE-2025-67644 і CVE-2026-28277 можуть бути об’єднані в ланцюжок для досягнення віддаленого виконання коду. Необхідна умова — застосунок має надавати доступ до ендпоінта get_state_history(), який дозволяє отримувати історичні контрольні точки за метаданими.

Послідовність атаки виглядає так:

1. Зловмисник формує корисне навантаження у форматі msgpack, що містить інструкції для виконання довільного коду.
2. Через SQL injection у параметрах фільтра зловмисник підміняє результат запиту до бази даних, повертаючи підроблений рядок контрольної точки, де стовпець checkpoint містить контрольовані зловмисником серіалізовані дані.
3. Застосунок обробляє результат запиту та десеріалізує шкідливий BLOB контрольної точки.
4. Небезпечна десеріалізація призводить до виконання корисного навантаження зловмисника на сервері.

Ключовий аспект цього ланцюжка — класична SQL injection стає вектором доставки для експлуатації вразливості десеріалізації. Без першої вразливості друга вимагала б прямого доступу на запис до сховища контрольних точок, що суттєво звужує поверхню атаки.

Позиція розробників і межі загрози

Мейнтейнери LangGraph охарактеризували CVE-2026-28277 як проблему постексплуатації: для успішного використання необхідна можливість запису контрольованих зловмисником даних у сховище контрольних точок. На їхню оцінку, типові конфігурації керованого хостингу спроєктовані так, щоб запобігати подібному доступу.

Ланцюжок експлуатації застосовний у самостійно розгорнутих інсталяціях, що використовують SQLite або Redis як сховище контрольних точок, за умови, що користувацьке введення передається в параметри фільтрації. Керована платформа LangSmith Deployment, як повідомляється, не піддається цим вразливостям. На момент розкриття не виявлено жодних свідчень активної експлуатації в реальних умовах.

Оцінка впливу

Найбільшому ризику піддаються організації, які розгорнули LangGraph у власній інфраструктурі для побудови ІІ-агентів із доступом до внутрішніх систем. У разі успішної експлуатації зловмисник отримує змогу виконувати довільний код у середовищі виконання агента, що може призвести до компрометації секретів середовища виконання та доступу до суміжних систем, доступних агентові.

Цей випадок наочно демонструє, як традиційні класи вразливостей — SQL injection і небезпечна десеріалізація — набувають підвищеної небезпеки в контексті фреймворків ІІ-агентів. Агенти, як правило, мають розширені привілеї та високий рівень довіри, що робить компрометацію їхнього середовища виконання значно руйнівнішою, ніж компрометацію звичайного вебзастосунку.

Рекомендації щодо усунення

• Оновіть уражені пакети: langgraph-checkpoint-sqlite до версії 3.0.1 і вище, langgraph до 1.0.10 і вище, @langchain/langgraph-checkpoint-redis до 1.0.1 і вище.
• Упровадьте автентифікацію для самостійно розгорнутих серверів LangGraph — ендпоінти на кшталт get_state_history() не мають бути доступні без авторизації.
• Усуньте довгоживучі статичні секрети із середовища виконання агентів; використовуйте ротацію облікових даних.
• Застосуйте мережеву сегментацію: ізолюйте середовище виконання ІІ-агентів від критичних внутрішніх систем.
• Розглядайте ІІ-агентів як привілейовані ідентичності та застосовуйте принцип найменших привілеїв для обмеження їхнього доступу.
• Валідуйте користувацьке введення перед передаванням у параметри фільтрації контрольних точок — не покладайтеся виключно на захист на рівні фреймворку.

Організаціям, які використовують LangGraph у самостійно розгорнутих конфігураціях, варто в пріоритетному порядку оновити всі три уражені компоненти та провести аудит доступності ендпоінтів керування станом агентів. Навіть за відсутності підтвердженої експлуатації в реальних умовах, наявність детального технічного опису ланцюжка атаки від Check Point суттєво знижує поріг для потенційних зловмисників.