В LangGraph обнаружили три уязвимости, две из которых можно было связать в атаку с удалённым выполнением кода на сервере. Для команд, которые уже тащат self-hosted AI-агентов в прод, это неприятный, но полезный сигнал: агентные фреймворки унаследовали не только гибкость, но и старые добрые проблемы вроде SQL-инъекций и небезопасной десериализации.
О проблеме сообщает The Hacker News со ссылкой на исследование Check Point. Речь идёт о LangGraph, open-source фреймворке от LangChain для построения stateful и multi-agent AI-приложений. Исследователь Ярден Порат раскрыл три уязвимости: CVE-2025-67644 с оценкой CVSS 7.3, CVE-2026-28277 с CVSS 6.8 и CVE-2026-27022 с CVSS 6.5. Исправления уже выпущены: для langgraph-checkpoint-sqlite уязвимы версии ниже 3.0.1, для основного пакета langgraph — ниже 1.0.10, для @langchain/langgraph-checkpoint-redis — ниже 1.0.1.
Самая опасная история здесь не в отдельной CVE, а в их комбинации. По данным Check Point, связка CVE-2025-67644 и CVE-2026-28277 позволяла довести атаку до RCE. Первая проблема — SQL-инъекция в SQLite-реализации checkpoint-механизма: атакующий мог подменять SQL-запрос через ключи фильтра метаданных. Вторая — небезопасная десериализация msgpack в LangGraph, из-за которой при загрузке checkpoint можно было инициировать восстановление объекта с вредоносной нагрузкой. В переводе на практический язык это значит следующее: если приложение открывает нужный endpoint и принимает недоверенный ввод, атакующий получает шанс не просто читать лишние данные, а запускать свой код на сервере.
Цепочка выглядела достаточно приземлённо, без магии и маркетинга вокруг AI. Атакующий подготавливал msgpack-payload с инструкциями для произвольного кода, затем отправлял вредоносный фильтр, эксплуатируя SQL-инъекцию так, чтобы запрос вернул поддельную строку checkpoint. После этого приложение обрабатывало результат, десериализовало BLOB и фактически исполняло полезную нагрузку злоумышленника. Ключевая точка входа — endpoint get_state_history(), который позволяет вытаскивать исторические checkpoint по метаданным. Если такой интерфейс доступен извне и параметры фильтра контролирует пользователь, уязвимости LangGraph превращаются из «теоретического риска» в вполне рабочий сценарий компрометации.
Третья проблема, CVE-2026-27022, затрагивает Redis-вариант checkpoint-хранилища. Это инъекция в RediSearch-запрос, которая может помочь обойти контроль доступа. Формально её оценили ниже, чем SQL-инъекцию в SQLite, но для self-hosted инсталляций это всё равно плохая новость: checkpoint-слой в агентных приложениях часто воспринимают как внутреннюю сервисную деталь, а не как поверхность атаки. На деле именно там живут состояние, история выполнения, промежуточные артефакты и метаданные, которые помогают атакующему либо эскалировать доступ, либо подготовить следующий шаг.
Отдельно важно, кого это не затронуло. Check Point и сами сопровождающие LangGraph подчёркивают, что managed-платформа LangSmith Deployment этой цепочке не подвержена. По описанию разработчиков, CVE-2026-28277 — постэксплуатационная уязвимость: для успешной атаки нужно уметь подсовывать контролируемые злоумышленником данные в checkpoint-хранилище и затем доводить это до исполнения кода в рантайме. Но это не повод расслабляться. В self-hosted мире именно такие «нужно ещё одно условие» часто оказываются нормой: где-то открыт внутренний endpoint, где-то фильтры прокидываются как есть, где-то Redis виден шире, чем должен, а секреты живут слишком долго.
Для разработчиков и IT-руководителей история неприятна ещё и тем, что она бьёт по самому удобному месту agentic-стека — доверию к фреймворку. AI-агенты почти по определению работают с повышенными привилегиями: имеют доступ к файлам, токенам, базам, корпоративным API, очередям, CRM и внутренним knowledge base. Поэтому классические баги в такой среде стоят дороже, чем в обычном веб-сервисе. Если атакующий получает выполнение кода в рантайме агента, дальше на столе уже не абстрактная «компрометация приложения», а доступ к секретам, данным и смежным системам, до которых агент может дотянуться по сети и учётным данным. Именно поэтому рекомендации здесь вполне традиционные и довольно скучные: срочно обновиться, включить аутентификацию на self-hosted серверах LangGraph, не держать долгоживущие статические секреты, сегментировать сеть и выдавать агентам только минимально необходимый набор прав.
На более широком уровне уязвимости LangGraph хорошо показывают, куда движется рынок безопасности AI-приложений. Шум вокруг «автономных агентов» не отменяет того факта, что они по-прежнему состоят из API, сериализации, хранилищ состояния, фильтров и запросов к базам. То есть из всего того, что ломали задолго до нынешнего бума на агентные платформы. Разница в том, что теперь цена ошибки выше: у приложения появился исполнитель с памятью, инструментами и доступом к инфраструктуре. Для русскоязычных команд, которые разворачивают такие системы у себя, главный вопрос уже не в том, будут ли появляться новые уязвимости LangGraph и аналогичных фреймворков, а в том, успеют ли их процессы безопасности догнать скорость внедрения AI-агентов.