Next.js випустив оновлення безпеки для гілок 15.5 і 16.3

30 вересня 2026 року Next.js випустив оновлення безпеки 16.3.8 і 15.5.27. Як пише Next.js Blog, виправлення однієї критичної уразливості та однієї уразливості високого рівня серйозності раніше відклали через затримку із залежностями. Тепер команда рекомендує оновити Next.js у застосунках. Серед проблем — підміна вмісту кешу, розкриття даних і серверні запити через оптимізацію зображень.

Яких застосунків це стосується

Версія 16.3.8 належить до гілки Active LTS, а 15.5.27 — до Maintenance LTS. Не кожна описана уразливість стосується всіх проєктів на Next.js: умови залежать від налаштувань зображень, способу розміщення застосунку, роутера, інструмента збирання та можливостей кешування.

Уразливість високого рівня серйозності в Image Optimization пов’язана з віддаленими зображеннями. Якщо зловмисник контролює URL, дозволений налаштуваннями застосунку, сервер може надіслати запит, наприклад, до діапазону приватних IP-адрес. Це Server-Side Request Forgery, або SSRF. Якщо images.remotePatterns не налаштовано, застосунок не вразливий до цієї проблеми.

Кілька помилок стосуються кешу сторінок. У застосунку, розміщеному на власному сервері, з Pages Router і сторінками SSG або ISR запис однієї сторінки може бути замінений вмістом іншого маршруту. Відвідувачі бачитимуть неправильний вміст до повторної перевірки запису. Застосунків на Vercel ця проблема не стосується.

Інший випадок пов’язаний із кореневим catch-all маршрутом у поєднанні зі статично генерованими маршрутами або ISR. Один спеціально сформований запит без авторизації може вплинути на спільний кеш відповідей. Коли ввімкнено Cache Components, вкладені функції use cache іноді формують ключ без кореневого параметра маршруту. Тоді вміст для одного значення параметра може потрапити у відповідь для іншого. Які саме значення буде розкрито, зловмисник обирати не може.

Є ризик і для редакційних попередніх переглядів. Якщо сайт використовує Cache Components або experimental.useCache, а кешовані функції повертають дані, що залежать від Draft Mode, одночасні запити редактора й відвідувача можуть використати одне ще не завершене заповнення кешу. Відвідувач отримає неопублікований вміст без авторизації. Якщо при цьому сторінка створюється заздалегідь, чернетка може зберегтися в ній і відображатися іншим відвідувачам до повторної перевірки.

Ще дві проблеми стосуються доступу до інформації. В App Router маршрути зображень метаданих, зокрема opengraph-image і twitter-image, під час збирання webpack ігнорують налаштування dynamicParams. Через це можна запитати зображення для динамічних сегментів, виключених із generateStaticParams(). Збірок Turbopack це не стосується. Інша помилка є лише в next dev: шкідливий сайт, відкритий розробником, може отримати через кінцеву точку Model Context Protocol шлях до проєкту, фрагменти коду з повідомлень про помилки, список маршрутів і логи. У робочому розгортанні ця кінцева точка недоступна.

Що перевірити команді сайту

Перший крок — з’ясувати, яка гілка Next.js використовується, і встановити відповідне оновлення: [email protected] для 16.3 або [email protected] для 15.5. Потім варто зіставити конфігурацію застосунку з умовами уразливостей, а не робити висновок лише на підставі використання Next.js.

Для сайту із зовнішніми зображеннями важливе налаштування images.remotePatterns. Для проєкту, розміщеного на власному сервері, з Pages Router — наявність сторінок SSG або ISR. Командам, які використовують Cache Components і Draft Mode, потрібно окремо перевірити роботу з редакційними чернетками: йдеться не лише про неправильну відповідь, а й про можливе відображення неопублікованого вмісту відвідувачам.

Власникам сайтів і маркетологам корисно розрізняти наслідки. В одному випадку відвідувач побачить вміст іншого маршруту, в іншому — може отримати чернетку. Проблема в next dev стосується середовища розробки, а не опублікованого сайту. Запитання до команди — які з перелічених можливостей використовуються в проєкті та чи оновлено залежність.

Моя думка

Я б не робив із цього релізу загального висновку про ненадійність Next.js. Описані сценарії мають різні умови: розміщення на власному сервері та Pages Router, робота з Draft Mode або запуск next dev. Невеликій команді, на мою думку, корисно мати просту карту проєкту: де формуються сторінки, що кешується і звідки завантажуються зображення.

Я б не відкладав оновлення лише тому, що частина пунктів здається незастосовною. Спочатку встановити виправлену версію своєї гілки, а потім перевірити налаштування й відповідні сценарії — такий порядок мені здається простішим, ніж розбиратися з конфігурацією вже після появи проблеми.

Джерела

Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.

1. September 2026 Security Release nextjs.org

Про автора

Павел Новак

досвідчений фулстек-розробник

Створюю вебсервіси для невеликих компаній у Брно. На старті намагаюся обрати стек, який команда зможе спокійно підтримувати за кілька років.

Усі публікації автора