abdugafforov-bobur/cve-2026-67620-pocCVE-2026-67620 - SSRF в Flowise из-за неполного deny-списка метаданных облака (Oracle OCI 192.0.0.192 + Alibaba 100.100.100.200 обходят DEFAULT_DENY_LIST)
Продукт: FlowiseAI/Flowise — визуальный конструктор LLM / AI-агентов (~54k ★)
Затронутые версии: ≤ 3.1.4 — подтверждено, что уязвимость сохраняется в 3.1.4, последнем релизе (повторно проверено 2026-08-06)
Уязвимость: Server-Side Request Forgery через неполный deny-list
CWE: CWE-918 (SSRF) · CWE-184 (Incomplete List of Disallowed Inputs)
Серьёзность: Средняя — CVSS 3.1 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
Обнаружено: 2026-07-10 · Сообщено в VulnCheck (CVD): 2026-07-15
Исследователь: Bobur Abdugafforov (Mahadsec)
Статус вендора — патч выпускаться не будет. Проект Flowise официально закрыт и больше не принимает сообщения об уязвимостях безопасности. Это уведомление публикуется, чтобы операторы, всё ещё использующие Flowise, могли самостоятельно устранить проблему.
Flowise поставляется с защитой от SSRF, которая блокирует запросы к сервисам метаданных облачных инстансов. Deny-list охватывает диапазон link-local 169.254.0.0/16, используемый AWS, GCP, Azure и DigitalOcean, — но не включает два адреса метаданных, которые не входят в этот диапазон:
| Облако | IP метаданных | В deny-list? |
|---|---|---|
| AWS / GCP / Azure / DigitalOcean | 169.254.169.254 | ✅ заблокирован |
| Oracle Cloud (OCI) | 192.0.0.192 | ❌ не заблокирован |
| Alibaba Cloud | 100.100.100.200 | ❌ не заблокирован |
Полный DEFAULT_DENY_LIST, поставляемый в официальном Docker-образе flowiseai/flowise:3.1.4
(.../flowise-components/dist/src/httpSecurity.js), выглядит так:
'0.0.0.0', '10.0.0.0/8', '127.0.0.0/8', '169.254.0.0/16', '169.254.169.253',
'169.254.169.254', '172.16.0.0/12', '192.168.0.0/16', '224.0.0.0/4', '240.0.0.0/4',
'255.255.255.255/32', '::1', 'fc00::/7', 'fd00:ec2::254', 'fe80::/10', 'ff00::/8',
'localhost', 'ip6-localhost'
18 записей. Ни 192.0.0.192, ни 100.100.100.200 не присутствуют, и ни один из них не попадает
внутрь какого-либо перечисленного CIDR — обратите внимание, что 192.168.0.0/16 не покрывает 192.0.0.192, и
записи 100.64.0.0/10 (CGNAT) нет вообще.
Список побайтово идентичен между 3.1.2 и 3.1.4. Единственное изменение в
httpSecurity.ts в этих выпусках — нормализация IPv4-mapped IPv6 внутри
isDeniedIP(), которая не может повлиять на два обычных IPv4-адреса.
Ни один из пропущенных адресов не попадает внутрь обычного частного или link-local CIDR:
192.0.0.192 находится внутри блока IETF Protocol Assignments 192.0.0.0/24 и выглядит
глобально маршрутизируемым, тогда как 100.100.100.200 находится в диапазоне CGNAT 100.64.0.0/10, который
deny-list также не покрывает. Защита, построенная на перечислении «метаданных IP» и
link-local диапазона, поэтому пропускает оба.
Аутентифицированный пользователь может заставить сервер Flowise выполнять произвольные GET-запросы к этим адресам. При развёртывании в OCI или Alibaba Cloud это достигает сервиса метаданных инстанса, который предоставляет идентификационные данные инстанса и учётные данные.
packages/components/src/httpSecurity.ts — DEFAULT_DENY_LIST
(скомпилировано: httpSecurity.js:31-50)
Список содержит 169.254.169.254 и диапазон 169.254.0.0/16, но не
содержит 192.0.0.192, 100.100.100.200 или диапазон CGNAT 100.64.0.0/10.
Поток запроса: GET /api/v1/fetch-links → checkDenyList(url) → secureFetch() через
webCrawl. secureFetch корректно повторно проверяет цели перенаправлений, поэтому обходы на основе
перенаправлений обрабатываются — дефект заключается в содержимом списка, из-за чего перенаправление
на любой из пропущенных IP проходит проверку так же, как и прямой запрос.
Маршрут fetch-links не имеет middleware checkPermission, поэтому любая аутентифицированная
сессия достигает его независимо от роли.
GET /api/v1/fetch-links?url=<target>&relativeLinksMethod=webCrawl&limit=1
Каждый узел, выполняющий маршрутизацию через secureFetch / secureAxiosRequest с URL, предоставленным пользователем,
подвержен действию того же deny-list — например, узлы web-scraper и HTTP-request.
Примечание о достижимости: проблема дополнительно достижима без аутентификации через
публичную конечную точку POST /api/v1/prediction/:id всякий раз, когда в чат-потоке присутствует узел, выполняющий выборку URL,
и этот чат-поток сделан публичным.
Подтверждено динамически на работающем локальном экземпляре Flowise 3.1.2 с прослушивателями, привязанными к
192.0.0.192:80 и 100.100.100.200:80.
Контроль — IP метаданных AWS/GCP/Azure корректно блокируется:
GET /api/v1/fetch-links?url=http://169.254.169.254/latest/meta-data/&relativeLinksMethod=webCrawl&limit=1
HTTP/1.1 500
isDeniedIP: Error: Access to this host is denied by policy.
Обход 1 — метаданные Oracle Cloud:
GET /api/v1/fetch-links?url=http://192.0.0.192/opc/v1/instance/&relativeLinksMethod=webCrawl&limit=1
HTTP/1.1 200
{"status":"OK","links":["http://192.0.0.192/opc/v1/instance"]}
Обход 2 — метаданные Alibaba Cloud:
GET /api/v1/fetch-links?url=http://100.100.100.200/&relativeLinksMethod=webCrawl&limit=1
HTTP/1.1 200
Запросы со стороны сервера, наблюдаемые на слушателях (доказывающие, что выборка исходила от сервера Flowise, а не от клиента):
# OCI listener
192.0.0.192 - - [11/Jul/2026 04:34:35] "GET /opc/v1/instance/ HTTP/1.1" 404 -
192.0.0.192 - - [11/Jul/2026 04:34:54] "GET /opc/v1/instance HTTP/1.1" 404 -
# Alibaba listener
100.100.100.200 - - [11/Jul/2026 04:34:35] "GET / HTTP/1.1" 200 -
100.100.100.200 - - [11/Jul/2026 04:34:54] "GET / HTTP/1.1" 200 -
PoC-скрипт включён как poc.py.
Любой аутентифицированный пользователь Flowise — а там, где узел выборки URL присутствует в публичном чатфлоу, и любой неаутентифицированный посетитель — может заставить сервер выполнять GET-запросы к сервисам метаданных экземпляров Oracle Cloud и Alibaba Cloud, что продукт явно пытается предотвратить для других провайдеров.
На уязвимом развёртывании это раскрывает данные идентичности экземпляра и эндпоинты метаданных, которые выдают учётные данные роли экземпляра, откуда следует дальнейший доступ к облачному аккаунту жертвы. В более широком смысле тот же пробел позволяет выполнять запросы в диапазон CGNAT 100.64.0.0/10, который маршрутизируется внутри многих сетей провайдеров.
Степень серьёзности отражает то, что эксплуатация требует размещения экземпляра Flowise в OCI или Alibaba Cloud. Сам дефект — неполный deny-list — не зависит от провайдера.
Патч от вендора выпущен не будет; проект закрыт. Операторам следует:
192.0.0.0/24 и 100.64.0.0/10 с хоста Flowise, — поскольку приложение исправить невозможно.PUT), чтобы обычный SSRF-GET не мог получить учётные данные.