Next.js 16.2.3 і 15.5.15: що закриває CVE-2026-23869 і що перевірити в App Router сьогодні

Next.jsSecurityFrontendDevOpsVulnerability Management

Коротко: Next.js 16.2.3 і 15.5.15 закривають CVE-2026-23869, а для команд на App Router це не новина «для галочки». Якщо у вас є зовнішній трафік на Server Function endpoints, затягування з апдейтом може перетворити звичайний реліз у дуже некрасивий простій.

Що саме змінилось

Vercel і Next.js випустили security-релізи для двох лінійок, щоб закрити проблему в частині React Server Components та App Router. Для більшості команд головне питання просте: чи зачіпає це ваш застосунок прямо зараз, чи ні.

Якщо у вас немає App Router, ризик нижчий. Якщо App Router є, а ще й endpoints доступні назовні, це вже не теорія, а робоча задача на сьогодні.

Чому це важливо

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

Для бізнесу це означає:

  • зіпсований user flow;
  • зайві 5xx;
  • нервовий реліз;
  • і потім ще «чому воно ламається тільки у вечірній пік».

Як діяти

1. Швидко визначте реальний ризик

Спочатку дивимось не на заголовок у новині, а на свій стек:

  • яка версія Next.js реально в lockfile;
  • чи використовується App Router;
  • які маршрути мають публічний трафік;
  • чи є server functions у цих маршрутах.

Якщо це комерційний сайт або продукт з інтернет-доступом, окремо подивіться на 5xx і latency за останні дні. Часто проблема проявляється саме там першою.

2. Оновіть не тільки пакет, а й спосіб доставки

Патч у package.json ще не означає, що прод уже захищений. Переконайтеся, що:

  • lockfile оновлений;
  • CI збирає саме нову версію;
  • новий білд реально задеплоєно;
  • старий артефакт не лишився на канарі або в кеші.

3. Не покладайтесь на WAF як на заміну апдейту

WAF і rate limiting корисні, але це лише додаткові ремені безпеки. Вони не замінюють оновлення Next.js.

Практичний порядок такий:

  1. оновити до безпечної версії;
  2. ввімкнути/посилити rate limiting на чутливих endpoint;
  3. перевірити WAF-правила;
  4. прогнати smoke test;
  5. викотити через canary, якщо ризик високий.

4. Зробіть короткий post-patch чек

Після релізу подивіться:

  • чи стартує застосунок без нових помилок;
  • чи не зросли 5xx;
  • чи не пішов p95 latency вгору;
  • чи працюють ключові user flow;
  • чи немає підозрілих помилок у маршрутах App Router.

5. Закріпіть захист у CI/CD

Додайте перевірку, яка не пропустить реліз із відомо старою версією Next.js. Це дешевше, ніж кожного разу ловити ті самі граблі руками.

Мінімум, що має бути в пайплайні:

  • перевірка версії залежності;
  • smoke test після білда;
  • canary або staged rollout для ризикових змін;
  • швидкий rollback, якщо метрики пішли не туди.

Типові помилки

  • Чекати “спокійнішого дня”. У security-релізів він зазвичай не настає.
  • Дивитися тільки в package.json. Реальна правда часто сидить у lockfile.
  • Думати, що WAF усе закриє. Ні, це лише підстраховка.
  • Викочувати все одразу без canary. Якщо щось піде не так, буде гірше відкатувати.

Висновок

Найкраща реакція на CVE-2026-23869 проста: підтвердити свій ризик, оновити Next.js до безпечної версії, перевірити App Router endpoints і закрити це CI-правилом, щоб історія не повторилася на наступному релізі.

Офіційні джерела:

Короткий чеклист

  • Перевірити фактичні версії next/react-dom у lockfile, а не тільки в package.json
  • Підтвердити, чи реально використовується App Router і уражені Server Function endpoints
  • Оновити Next.js до fixed version у своїй лінійці
  • Прогнати smoke test і перевірити 5xx, latency та лог-помилки
  • Додати CI gate, який блокує реліз зі старою вразливою версією

Prompt Pack: Next.js CVE response playbook

Ти — frontend security engineer для Next.js застосунку. Потрібно швидко підготувати план реагування на CVE-2026-23869. Вхідні дані: - поточна версія next і react-dom у package.json / lockfile; - чи використовує застосунок App Router і Server Function endpoints; - які маршрути мають зовнішній трафік; - чи є WAF, rate limiting і canary rollout; - поточні метрики 5xx і latency. Потрібно повернути: 1) короткий triage risk assessment; 2) чіткий порядок дій на 60 хвилин; 3) список перевірок після оновлення; 4) CI/CD guardrails, щоб не випустити вразливу збірку ще раз. Формат відповіді: - 5 коротких блоків; - без теорії заради теорії; - окремо познач, де потрібен canary, а де досить smoke test.