Критическую уязвимость CVE-2026-5027 в Langflow уже используют в атаках. Ошибка позволяет записывать произвольные файлы на открытые серверы через небезопасную обработку имени файла в механизме загрузки.

Проблема затрагивает платформу для сборки AI-приложений и агентов без ручного кодинга. По данным исследователей, атакующим достаточно одного запроса к уязвимому endpoint, если сервер торчит в интернет и не закрыт дополнительными мерами.

1. История инцидента

Langflow — open source-платформа для визуальной сборки AI-решений, включая RAG-системы и рабочие процессы с перетаскиванием блоков. Проект широко используют команды разработки, а число звёзд на GitHub уже перевалило за 149 тысяч.

Проблему нашла компания Tenable. Она указывает, что endpoint POST /api/v2/files не очищал параметр filename из multipart-данных, а значит атакующий мог подсовывать последовательности ../ и уводить запись файла в нужное место на сервере.

Tenable раскрыла уязвимость 27 марта 2026 года, после того как без ответа отправила отчёт разработчикам ещё в начале года. Позже Snyk Security сообщила, что исправление вошло в пакет langflow-base 0.8.3, а сам Langflow получил патч в версии 1.9.0. Сейчас разработчикам советуют обновиться до 1.10.0.

2. Что пошло не так в защите

Корень проблемы — слабая проверка входных данных. Сервис не отфильтровал имя файла, поэтому путь внутри системы можно было подменить с помощью path traversal — техники, когда злоумышленник добавляет фрагменты вроде ../ и выходит за пределы ожидаемой директории.

Вторая ошибка — слишком лёгкий вход в систему. Исследователь Caitlin Condon из VulnCheck пишет, что в Langflow по умолчанию включён автологин без аутентификации. Иначе говоря, атакующему не нужны логин и пароль, чтобы добраться до опасного endpoint, а затем получить валидный токен сессии.

Похожий сценарий уже встречался и в других продуктах для разработки и инфраструктуры. Когда сервис работает на открытом сервере, одна недоработка в обработке файлов превращается в точку входа для атаки — как это уже было в разборе уязвимости в Ivanti Sentry и в истории с zero-day-дырой в Microsoft.

Отдельный риск — публичная экспозиция. По данным Censys, исследователи нашли около 7 тысяч открытых экземпляров Langflow, но эта цифра может включать старые сканы и не отражать текущее число доступных систем.

3. Уроки для читателя

История Langflow снова показывает простую вещь: уязвимость в сервисе разработки — это не абстрактная проблема для инженеров, а риск для всей инфраструктуры. Если платформа умеет загружать файлы, а доступ к ней открыт наружу, у атакующего появляется шанс записать что угодно туда, куда ему нельзя.

Для компаний вывод особенно неприятный. Инструменты для AI-разработки часто подключают быстро, без жёсткой настройки, а потом забывают проверить их как полноценный серверный сервис. Именно на этом и ловят жертву: слабая аутентификация, лишняя открытая поверхность, задержка с обновлениями.

Домашним пользователям эта история тоже полезна. Любой веб-сервис, который вы запускаете локально или держите в облаке, надо воспринимать как публичный актив, если он доступен из интернета. Обновления, ограничение доступа и контроль загружаемых файлов — не формальность, а базовая гигиена.

Если вы работаете с сервисами в поездке или с общедоступных сетей, стоит подумать и о дополнительном шифровании трафика на личных устройствах. Для этого можно использовать [решение для шифрования трафика в поездках]https://freedome.space — как один из слоёв защиты, а не как замену обновлениям и нормальной настройке сервиса.

4. Практические выводы и чек-лист

Случай Langflow полезно разобрать не только как новость об очередной уязвимости, но и как памятку по защите своих систем. Вот что стоит сделать прямо сейчас.

Проверьте, не используете ли вы Langflow и какие версии стоят на сервере.
Обновите платформу до версии 1.10.0 или до того релиза, где закрыта CVE-2026-5027.
Уберите из интернета всё, что не должно быть публичным: тестовые инстансы, панели администрирования, сервисы разработки.
Отключите лишние автоматические сценарии входа, если они не нужны по работе.
Ограничьте доступ к загрузке файлов и проверьте, как сервис обрабатывает имена и пути.
Логируйте попытки загрузки и ищите аномалии: неожиданные расширения, странные пути, повторяющиеся ошибки.
Проверьте, не повторяются ли похожие слабые места в других внутренних инструментах — особенно там, где есть загрузка файлов и веб-панель.
Если сервис нужен сотрудникам вне офиса, заранее настройте защищённый доступ, а не держите его открытым наружу.

Для тех, кто отвечает за защиту инфраструктуры, этот кейс — ещё один аргумент в пользу регулярной проверки правил детекта. Атакующие не ждут, пока вы разберётесь с обновлением, и всё чаще бьют по сервисам, которые разработчики считают вспомогательными.