Уязвимость SSRF в Next.js позволяет похищать облачные учётные данные

Представьте консьержа в отеле, который с радостью звонит в любой номер здания по просьбе гостя, не задавая лишних вопросов. В большинстве случаев это удобная функция. Но когда посторонний входит и просит консьержа позвонить в сейф управляющего и зачитать комбинацию, это становится худшей должностной инструкцией в здании. Примерно это и произошло с обработчиком WebSocket upgrade в стандартном Node.js-сервере Next.js.

15 мая 2026 года в экосистеме Next.js была обнаружена высококритическая SSRF-уязвимость, и теперь у всех, кто эксплуатирует собственную инфраструктуру, за стойкой регистрации сидит консьерж с очень плохим суждением.

Что произошло

Уязвимость зарегистрирована как CVE-2026-44578, а также как GHSA-c4j6-fc7j-m34r на GitHub. Как сообщил CyberSecurityNews, проблема заключается в том, как встроенный Node.js-сервер Next.js обрабатывает WebSocket upgrade-запросы. Специально сформированный upgrade-запрос заставляет сервер действовать как прокси, перенаправляя полезную нагрузку атакующего туда, куда ему нужно: во внутреннюю административную панель, в endpoint сервисной сети или к сервису облачных метаданных, расположенному по link-local адресу, которого боится каждый backend-инженер.

Уязвимость раскрыл Tim Neutkens на GitHub, и команда сопровождения Next.js выпустила патчи для двух отдельных веток релизов. Исправленные версии — 15.5.16 и 16.2.5. В исправленной сборке сервер проксирует WebSocket upgrade-запросы только в том случае, если конфигурация маршрутизации явно помечает их как безопасные внешние перезаписи. Запрет по умолчанию, явное разрешение при необходимости. Это правильный подход для подобного рода функциональности, и, пожалуй, он должен был быть таким с самого начала.

Два уточнения, важных для оценки масштаба последствий. Во-первых, это исключительно проблема self-hosted развёртываний. Приложения, работающие на Vercel, полностью защищены, поскольку инфраструктура Vercel не использует уязвимую реализацию WebSocket-маршрутизации. Во-вторых, это не теоретическая угроза. Описываются случаи, когда атакующие опрашивают внутренние сетевые сервисы, получают доступ к незащищённым административным панелям и обращаются к облачным metadata endpoint, которые могут вернуть временные IAM-учётные данные, API-токены и секреты развёртывания в одном ответе. Любой, кто видел, как разворачивается цепочка SSRF с кражей токенов в ходе разбора инцидентов, знает, насколько короткий путь от «странного WebSocket» до «атакующий получил нашу роль для деплоя».

Публичная запись CVE находится в стандартной системе MITRE CVE под номером CVE-2026-44578.

Техническая анатомия

Суть проблемы удручающе проста. В HTTP/1.1 существует небольшая церемония под названием upgrade handshake: клиент говорит «я хотел бы переключить протоколы, пожалуйста», и сервер, если он согласен, передаёт сокет другому участку кода. WebSocket работает поверх этого механизма. Внутри фреймворка Next.js сервер должен решить, что делать с upgrade-запросом: завершить его локально, проигнорировать или перенаправить к какому-либо upstream, определённому в конфигурации маршрута.

Уязвимое поведение, согласно раскрытию, состоит в том, что сервер по умолчанию перенаправлял upgrade-запросы в ситуациях, когда не должен был. Атакующий отправляет специально сформированный upgrade, и процесс Next.js послушно открывает соединение с адресатом, который контролирует атакующий. Поскольку сам сервер выполняет исходящий запрос, он обходит внешние межсетевые экраны. Пакеты больше не приходят из публичного интернета. Они исходят от доверенного узла внутри вашего VPC, со всеми правилами egress и IAM-контекстом, которыми этот узел располагает.

Дальше следует классический SSRF. Самая лакомая цель в любом облачном Node-процессе — metadata endpoint: link-local адрес, возвращающий учётные данные роли инстанса. Успешное обращение к нему даёт краткосрочные, но вполне реальные IAM-токены. Другие пути ведут ко внутренним административным панелям, которые считались «безопасными» из-за недоступности снаружи, к экземплярам Redis или Elasticsearch, никогда не ожидавшим аутентифицированного вызывающего, и ко всему остальному, что находится в приватной подсети. Это OWASP A10:2021 в учебниковой форме, применённый как оружие через фреймворк, который большинство команд воспринимают как чёрный ящик.

Дизайн патча говорит кое-что о мышлении сопровождающих. Вместо того чтобы пытаться санировать адреса назначения или искать паттерны для IP-адресов метаданных (проигрышная игра для всех, кто пытался заблокировать 169.254.169.254 через IPv6, DNS rebinding и цепочки редиректов), они сменили значение по умолчанию. Никакого проксирования, пока конфигурация маршрута не скажет: «да, это внешняя перезапись, и я это имею в виду». Это правильный шаг. Скучная часть в том, что большинство команд не осознают, что у них было неявное поведение по перенаправлению upgrade-запросов, пока не прочитают changelog.

Кто пострадает

Под угрозой находятся все, кто запускает self-hosted Next.js на стандартном Node.js-сервере. На практике это длинный список: операторы iGaming, перенёсшие свой публичный стек внутрь компании из соображений задержки или соответствия требованиям, fintech-команды, которые не могут передавать данные клиентов через стороннюю edge-платформу, крипто-фронтенды, явно выбравшие self-hosting, чтобы ни один вендор не мог «выдернуть вилку из розетки», и любые корпоративные клиенты, запускающие Next.js внутри регулируемого VPC.

Сценарий с iGaming меня беспокоит больше всего. Букмекерские конторы, как правило, запускают административные панели для торговых отделов, контроля рисков и управления игроками во внутренних подсетях, исходя из допущения, что публичный веб-уровень не может до них добраться. SSRF на публичном веб-уровне разрушает это допущение в один шаг. Если тот же кластер Kubernetes также обслуживает витрину магазина, у атакующего теперь есть прокси на торговую площадку.

У fintech-команд — другой вариант той же проблемы. Границы PCI scope и SOC 2, как правило, проведены по сети. Веб-фронтенд, который вдруг может обращаться к внутренним сервисам или, что хуже, получать AWS-учётные данные через metadata endpoint, пробивает дыры в аудиторских допущениях, на составление которых ушли месяцы.

Крипто-фронтенды несут особый риск: если self-hosted Next.js-сервер имеет какие-либо ключи подписи, секреты развёртывания или RPC-учётные данные, кэшированные локально или доступные в той же сети, атакующий, получив облачные metadata-токены, может быстро продвинуться дальше. Следующие 90 дней для этих команд должны включать в себя ротацию учётных данных вне зависимости от того, считают ли они, что были атакованы, поскольку временные IAM-токены утекают без шума, а логов для подтверждения отсутствия инцидента зачастую не существует.

Клиентам Vercel, если говорить прямо, беспокоиться не о чем. Это реальный архитектурный дивиденд управляемого пути. Это также полезный аргумент в следующий раз, когда CFO спросит, почему счёт за хостинг не ниже.

Руководство для команд безопасности

Шаг первый на этой неделе: обновитесь. Next.js 15.5.16, если вы на ветке 15.x, или 16.2.5, если на 16.x. Никаких умных промежуточных вариантов. Патч изменяет поведение по умолчанию, поэтому протестируйте свои маршруты, особенно те, которые реально используют WebSocket rewrites для upstream, — им теперь потребуется явная конфигурация для продолжения работы.

Там, где патч на этой неделе невозможен (а такой сервис всегда найдётся — застрявший на старой сборке из-за привязки версии Node или замороженного образа от вендора), раскрытие рекомендует два компенсирующих контроля. Первый: настройте обратный прокси или балансировщик нагрузки на блокировку всех WebSocket upgrade-запросов, если приложение активно их не использует. Удаление заголовков Connection и Upgrade в nginx перед origin — это пятиминутное изменение с очень высокой отдачей. Второй: ограничьте исходящий трафик origin-сервера. Заблокируйте egress к внутренним облачным metadata-сервисам и к не связанным с ним внутренним сетям на уровне security group или сетевых политик.

Для пользователей AWS в частности, переход на IMDSv2 с hop-limit равным 1 уже много лет является лучшей практикой и является наиболее эффективным шагом по защите именно от этой цепочки атак. Если вы ещё не сделали это, вот ваш повод. Сопоставьте TTP с MITRE ATT&CK T1552.005 (Cloud Instance Metadata API), когда будете писать разбор инцидента, — кто-то в вашей организации обязательно спросит.

Наконец, проведите расследование. Проверьте логи доступа на предмет нетипичных запросов Upgrade: websocket, особенно с нестандартными заголовками Host или адресатами, не соответствующими вашему обычному трафику. Если вы обнаружите такие запросы до установки патча — считайте, что учётные данные скомпрометированы, и проведите ротацию.

Ключевые выводы

• CVE-2026-44578 — высококритическая SSRF-уязвимость в обработчике WebSocket upgrade стандартного Node.js-сервера Next.js, раскрытая Tim Neutkens.
• Немедленно обновитесь до Next.js 15.5.16 или 16.2.5. Патч переводит проксирование upgrade-запросов в режим явного разрешения через конфигурацию безопасных внешних перезаписей.
• Уязвимы только self-hosted развёртывания. Приложения на Vercel не подвержены уязвимости, так как Vercel не использует уязвимый путь WebSocket-маршрутизации.
• Если патч установить невозможно, заблокируйте WebSocket upgrade на обратном прокси и ограничьте egress origin-сервера к облачным metadata endpoint и не связанным внутренним подсетям.
• Аналогия с консьержем работает: когда стойка регистрации готова набрать любой номер по запросу, единственная безопасная политика — это список гостей. Запрет по умолчанию на внутреннее проксирование — единственная архитектура, выдерживающая контакт с решительным атакующим.