Уязвимость в Langchain: Ошибка в веб-сборщике данных угрожает безопасности облачной инфраструктуры

В сфере разработки, связанной с искусственным интеллектом, безопасность инструментов для обработки данных становится критически важной. Команда разработчиков популярного фреймворка Langchain выпустила экстренное обновление для пакета "@langchain/community", устраняющее опасную уязвимость типа Server-Side Request Forgery (подделка межсайтовых запросов). Эта проблема, получившая идентификатор CVE-2026-26019, затрагивает класс "RecursiveUrlLoader", используемый для веб-краулинга (автоматизированного сбора данных с веб-страниц). Если её не исправить, злоумышленники могут обходить ограничения и заставлять приложение обращаться к внутренним сетевым ресурсам или конфиденциальным метаданным облачных сервисов, что создаёт серьёзные риски для целостности инфраструктуры.

Детали уязвимости

Суть уязвимости кроется в недостаточной валидации (проверке) URL-адресов во время работы краулера. В классе "RecursiveUrlLoader" существует опция "preventOutside", включённая по умолчанию, призванная ограничить сборщик данных только сайтом, с которого начался обход. Однако реализация этой защиты была ошибочной и полагалась на простое сравнение строк с помощью метода "String.startsWith()", а не на строгий семантический анализ происхождения (origin) URL. Этот метод создал значительную брешь, позволив злоумышленнику сконструировать вредоносный домен, который начинается с того же префикса, что и целевой. Например, если краулер должен работать только в пределах "https://example.com", его можно было обманом направить на "https://example.com.attacker.com". Строковая проверка считала такой адрес разрешённым, поскольку он технически начинался с заданной строки, хотя домен был совершенно другим.

Помимо этой ошибки сравнения, предыдущая версия сборщика данных также не проверяла адреса на принадлежность к частным (private) или зарезервированным диапазонам IP-адресов. Это означало, что если атакующий мог повлиять на содержимое сканируемой страницы, например, через размещённые пользователями комментарии или данные, он мог внедрить ссылки, указывающие на чувствительные внутренние службы. Краулер слепо переходил бы по этим ссылкам и загружал ресурсы, включая конечные точки (endpoints) служб метаданных, используемых крупными облачными провайдерами, такими как AWS, Google Cloud и Microsoft Azure. Доступ к этим метаданным - распространённая тактика киберпреступников для кражи учётных данных IAM (управления доступом) и токенов сессий, что в конечном итоге может привести к полному компрометации облачной инфраструктуры. Кроме того, краулер можно было направить на сканирование внутренней сети организации или обращение к службам, работающим на локальном хосте (localhost), что расширяет поверхность атаки.

Уязвимость, оценённая по шкале CVSS (Common Vulnerability Scoring System) в 6.1 балла (умеренный уровень опасности), затрагивает все версии пакета "@langchain/community" вплоть до 1.1.13 включительно. В исправленной версии 1.1.14 были реализованы два ключевых улучшения безопасности. Во-первых, ошибочное строковое сравнение заменено на строгую проверку происхождения с использованием стандартного URL API, которая гарантирует точное совпадение схемы (протокола), имени хоста и порта. Во-вторых, был добавлен новый модуль валидации SSRF, который запускается перед каждым исходящим запросом. Этот модуль явным образом блокирует подключения к частным диапазонам IP-адресов, адресам петлевого интерфейса (loopback), а также к известным конечным точкам метаданных облаков, таким как "169.254.169.254" (стандартный адрес для метаданных в AWS и других средах).

Для разработчиков, использующих библиотеки Langchain в своих проектах, рекомендация очевидна: необходимо немедленно обновить зависимость "@langchain/community" до версии 1.1.14. Если немедленное обновление по каким-либо причинам невозможно, следует принять временные меры митигации (снижения риска). Крайне не рекомендуется запускать "RecursiveUrlLoader" на ненадёжном контенте, сгенерированном пользователями, без дополнительных мер контроля. Альтернативой может стать развёртывание приложения в изолированной сетевой среде, где доступ к внутренним службам и API метаданных облака жёстко ограничен сетевыми правилами и брандмауэрами. Этот инцидент служит важным напоминанием о том, что даже встроенные механизмы безопасности в популярных библиотеках требуют тщательного аудита, особенно когда речь идёт о компонентах, взаимодействующих с внешними сетевыми ресурсами. Устранение подобных логических уязвим

Детали уязвимости

Ссылки