Вразливість 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-запит змушує сервер діяти як проксі, пересилаючи корисне навантаження зловмисника туди, куди він забажає: на внутрішню панель адміністратора, до ендпоінту сервісної мережі або до хмарного metadata-сервісу на link-local-адресі, якої побоюється кожен бекенд-інженер.

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

Два уточнення, що мають значення для оцінки масштабів наслідків. По-перше, це виключно проблема самостійного хостингу. Застосунки, що працюють на Vercel, повністю захищені, оскільки інфраструктура Vercel не використовує вразливу реалізацію WebSocket-маршрутизації. По-друге, це не теоретичний сценарій. Описуються атаки на внутрішні мережеві сервіси, незахищені адмін-панелі та хмарні metadata-ендпоінти, які можуть віддати тимчасові IAM-облікові дані, API-токени та секрети розгортання в одній відповіді. Будь-хто, хто спостерігав за розгортанням ланцюжка SSRF із крадіжкою токенів у постмортемі, знає, наскільки короткий шлях від «дивного WebSocket» до «зловмисник має нашу роль розгортання».

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

Технічна Анатомія

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

Вразлива поведінка, згідно з розкриттям, полягає в тому, що дефолтний сервер пересилав upgrade-запити в сценаріях, де цього не слід робити. Зловмисник надсилає спеціально сформований upgrade, і процес Next.js старанно відкриває з'єднання до пункту призначення, на який зловмисник впливає. Оскільки сам сервер виконує вихідний запит, він обходить зовнішні фаєрволи. Пакети більше не надходять з публічного інтернету. Вони надходять від довіреного хоста всередині вашого VPC, із якими б правилами egress та IAM-контекстом цей хост не мав.

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

Дизайн патча багато говорить про мислення розробників. Замість спроб санітизувати пункти призначення або шукати metadata IP за шаблоном (програшна гра, як може підтвердити будь-хто, хто намагався заблокувати 169.254.169.254 через IPv6, DNS rebinding та ланцюжки редиректів), вони змінили дефолт. Жодного проксіювання, якщо конфігурація маршруту не каже «так, це зовнішній rewrite, і я це мав на увазі». Це правильний крок. Невтішна частина полягає в тому, що більшість команд не усвідомлять, що мали неявну поведінку пересилання upgrade, доки не прочитають changelog.

Хто Постраждає

Під загрозою всі, хто запускає самостійно розгорнутий Next.js на дефолтному Node.js-сервері. На практиці це довгий список: iGaming-оператори, які перенесли свій стек для гравців на власну інфраструктуру з міркувань затримки або відповідності вимогам, fintech-команди, які не можуть передавати дані клієнтів через сторонню edge-платформу, крипто-фронтенди, що свідомо обрали самостійний хостинг, щоб жоден постачальник не міг відключити їх, та будь-яке підприємство, що запускає Next.js усередині регульованого VPC.

Найбільше мене турбує кут зору iGaming. Букмекерські контори зазвичай тримають адмін-панелі для торгових відділів, управління ризиками та менеджменту гравців у внутрішніх підмережах, за припущенням, що публічний веб-рівень не може до них дістатися. SSRF у публічному веб-рівні руйнує це припущення за один крок. Якщо той самий Kubernetes-кластер також запускає сторфронт, зловмисник тепер має проксі всередину торгового залу.

Fintech-команди мають дещо іншу версію тієї ж проблеми. Межі PCI scope та SOC 2 зазвичай проводяться по мережі. Веб-фронтенд, який раптово може звертатися до внутрішніх сервісів або, що гірше, отримувати AWS-облікові дані через metadata-ендпоінт, пробиває діри в аудиторських припущеннях, на формування яких пішли місяці.

Крипто-фронтенди несуть особливий ризик: якщо самостійно розгорнутий Next.js-хост має будь-які ключі підпису, секрети розгортання або RPC-облікові дані, кешовані локально або доступні в тій самій мережі, зловмисник, що забирає хмарні metadata-токени, може швидко здійснити pivot. Наступні 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 на режим opt-in через явну конфігурацію безпечних зовнішніх rewrites.
• Зачіпає лише самостійно розгорнуті інстанції. Застосунки, розгорнуті на Vercel, не вразливі, оскільки Vercel не використовує уражений шлях WebSocket-маршрутизації.
• Якщо оновлення неможливе, видаліть WebSocket upgrade на зворотному проксі та заблокуйте egress origin до хмарних metadata-ендпоінтів та непов'язаних внутрішніх підмереж.
• Аналогія з консьєржем залишається актуальною: коли ресепшен набирає будь-який номер на прохання, єдина безпечна політика — це список допущених гостей. Заборона за замовчуванням для внутрішнього проксіювання — єдина архітектура, яка витримує зіткнення з цілеспрямованим зловмисником.