Уязвимость PraisonAI начали проверять на бою меньше чем через четыре часа после публичного раскрытия: первый целевой запрос к уязвимому endpoint зафиксировали 11 мая 2026 года в 17:40 UTC. Для тех, кто разворачивает AI-агентов в проде, это неприятное, но полезное напоминание: окно между публикацией advisory и реальной атакой теперь измеряется не днями, а часами.
По данным The Hacker News, речь идет о CVE-2026-44338 с оценкой 7,3 по CVSS. Проблема связана с отсутствием аутентификации в legacy API-сервере PraisonAI на Flask: если этот сервер используется и доступен по сети, любой клиент может обращаться к чувствительным endpoint без токена. В практическом смысле это означает доступ к маршруту /agents, который позволяет увидеть конфигурацию агентного файла, и к /chat, через который можно запустить workflow из agents.yaml.
PraisonAI — open source-фреймворк для оркестрации мультиагентных систем. Уязвимым оказался файл src/praisonai/api_server.py, где, по сообщению мейнтейнеров, значения AUTH_ENABLED = False и AUTH_TOKEN = None захардкожены в legacy-реализации. То есть защита не просто настроена плохо, а фактически отключена по умолчанию. Для разработчика это тот случай, когда слово legacy внезапно означает не только «старый код, который руки не доходят убрать», но и «открытая дверь в ваш агентный рантайм».
Диапазон затронутых версий широкий: от 2.5.6 до 4.6.33 включительно. Исправление вышло в версии 4.6.34. Уязвимость обнаружил и сообщил о ней исследователь Шмулик Коэн. Сам вендор отдельно подчеркнул, что последствия зависят от того, что именно разрешено в agents.yaml. Но базовая проблема не зависит от сценария использования: bypass аутентификации срабатывает без дополнительных условий, если наружу торчит именно этот API-сервер.
На практике список рисков вполне приземленный и потому неприятный. Во-первых, посторонний может без авторизации перечислить конфигурацию агентов через /agents. Во-вторых, можно триггерить локально настроенный workflow через /chat. В-третьих, появляется возможность просто сжигать модельную или API-квоту повторяющимися запросами. В-четвертых, неавторизованный клиент может получить результаты выполнения PraisonAI.run(). Если агентная схема завязана на внутренние API, внешние сервисы, чувствительные промпты, файлы или автоматические действия, история быстро перестает быть «просто багом в экспериментальном AI-стеке».
Самый показательный фрагмент этой истории — скорость реакции атакующих. Компания Sysdig сообщила, что увидела попытки эксплуатации через 3 часа 44 минуты после публикации advisory. Временная шкала выглядит без лишней драмы: advisory появился 11 мая 2026 года в 13:56 UTC, а первый целевой запрос пришел в 17:40 UTC того же дня. Активность шла с IP-адреса 146.190.133.49 и выглядела как работа упакованного сканера с User-Agent CVE-Detector/1.0.
По наблюдениям Sysdig, сканер прошел двумя сериями с интервалом в восемь минут. Каждая серия включала около 70 запросов примерно за 50 секунд. В первой волне проверялись типовые пути вроде /.env, /admin, /users/sign_in, /eval, /calculate и /Gemfile.lock. Во второй волне уже явно искали поверхности, связанные с AI-агентами, включая PraisonAI. Ключевой запрос для CVE-2026-44338 был предельно простой: GET /agents без заголовка Authorization. Сервер ответил 200 OK и вернул тело с указанием agent_file: agents.yaml и списком агентов, тем самым подтвердив, что обход аутентификации работает.
Важно, что Sysdig не увидела попыток отправить POST на /chat. То есть на момент наблюдения атакующие скорее валидировали наличие уязвимой инсталляции, чем сразу запускали чужие workflow. Для защитника это не повод расслабляться, а наоборот, довольно знакомый паттерн: сначала массовое картирование поверхности атаки, потом — либо продажа списка уязвимых хостов, либо повторный заход уже с конкретной полезной нагрузкой. В мире облаков и автоматизированных сканеров разведка давно стала почти мгновенной услугой.
Для русскоязычной IT-аудитории здесь есть несколько очень прикладных выводов. Разработчикам стоит проверить, не остался ли в окружении legacy Flask API-сервер PraisonAI и не опубликован ли он наружу по привычке «пусть пока так поработает». Тимлидам и платформенным инженерам — перепроверить версии пакета: все сборки от 2.5.6 до 4.6.33 требуют обновления до 4.6.34. Тем, кто уже использовал PraisonAI в тестовых или внутренних контурах, имеет смысл не ограничиваться патчем: нужно просмотреть логи доступа к /agents и /chat, проверить аномалии в биллинге модельных провайдеров и пересмотреть секреты, на которые ссылается agents.yaml. Если в этой конфигурации лежат токены, ключи к SaaS или параметры внутренних интеграций, их ротация выглядит не бюрократией, а базовой гигиеной.
Для бизнеса история тоже показательная. Еще недавно многие компании смотрели на агентные фреймворки как на что-то полуэкспериментальное: удобно для прототипа, не очень интересно для серьезных атакующих. Но уязвимость PraisonAI показывает обратное. Инструментарий злоумышленников уже масштабировался на весь AI-экосистемный хвост — не только на громкие бренды, но и на нишевые open source-компоненты. Если продукт по умолчанию публикует незащищенный интерфейс, его начнут дергать почти сразу после disclosure, даже если о проекте знают в основном разработчики и энтузиасты.
Главный вывод здесь не в том, что очередной CVE быстро попал в сканеры. Это уже почти норма. Вопрос в другом: готовы ли команды обращаться с агентными фреймворками так же строго, как с любой другой внешней API-поверхностью. Пока часть рынка все еще разворачивает AI-инструменты с поправкой на «это же внутренний сервис», атакующие уже работают с поправкой на то, что внутренние сервисы слишком часто оказываются вполне внешними.