Next.js анонсував плановий security release на вівторок, 3 листопада 2026 року – він закриє сім вразливостей рівня medium. Advisories з деталями про impact, affected versions і upgrade instructions команда опублікує разом з релізом, а не заздалегідь. Поки що це все, що відомо офіційно – і це нормально, бо advance notice для того й існує, щоб дати командам час підготуватись, а не щоб розкрити вразливості до патча.

Чому варто звернути увагу вже зараз

Якщо твій застосунок на Next.js стоїть у продакшені – неважливо, self-hosted це чи на Vercel – advance notice означає одне: у тебе є кілька днів, щоб підготувати процес оновлення до того, як вийдуть деталі. Це особливо актуально для команд, де Next.js тягнеться у dependency tree не тільки напряму, а й через внутрішні пакети чи monorepo.

Проблема в тому, що «medium severity» – це доволі широка категорія. Вона може означати і щось типу DoS при специфічних заголовках запиту, і щось ближче до SSRF чи XSS у вузькому сценарії. Без advisories гадати безглуздо – і саме тому варто не чекати на CVE-номер, а підготувати механіку швидкого апгрейду заздалегідь.

Схожий патерн advance notice нещодавно використовував і Node.js – детальніше про те, як там був побудований процес підготовки, можна подивитись у матеріалі Node.js готує security release 21 жовтня: що зробити до появи CVE. Корисно порівняти обидва підходи – екосистема явно рухається в бік публічних попереджень за кілька днів до релізу.

Що саме анонсував Next.js

Сам анонс короткий і структурований навколо трьох фактів:

  • дата релізу – 3 листопада 2026;
  • кількість вразливостей – сім, усі рівня medium;
  • advisories (impact, affected versions, upgrade instructions) з’являться одночасно з релізом, не раніше.

Команда також нагадує, що працює з дослідниками безпеки через Vercel’s Open Source Bug Bounty program, і що питання щодо security-процесів можна надсилати на security@vercel.com. Це стандартна практика розкриття вразливостей (responsible disclosure) – дослідники повідомляють приватно, вендор готує патч, і тільки після релізу публікується повний опис. Логіка зрозуміла: публікація деталей до патча дала б зловмисникам фору.

Важливо не плутати модальність: реліз ще не вийшов, advisories ще не опубліковані. Усе, що зараз можна зробити – це підготуватись організаційно, а не технічно латати щось конкретне.

Як підготуватись, поки деталей немає

Головна практична дія зараз – переконатись, що апгрейд Next.js у твоєму проєкті не перетвориться на пригоду. Ось простий чекліст, який можна прогнати до 3 листопада:

  1. Зафіксуй поточну версію Next.js у всіх застосунках команди. Якщо в тебе кілька репозиторіїв або monorepo – вони можуть жити на різних версіях, і це нормально виявиться тільки в момент кризи.

  2. Перевір, чи є в CI крок, який показує застарілі залежності. Найпростіший варіант – регулярний запуск npm outdated для ключових пакетів:

{
  "scripts": {
    "check:next": "npm outdated next --json || true"
  }
}

  1. Додай нагадування на 3 листопада – буквально календарна подія для того, хто відповідає за залежності в команді, щоб перевірити advisories одразу після публікації.

  2. Переглянь, як у вас влаштований процес від «вийшов патч» до «задеплоєно в продакшн». Якщо це тижні ручних погоджень – саме час це скоротити, поки немає тиску реальної вразливості.

Якщо у вас в CI вже налаштований Dependabot або аналогічний інструмент на автоматичні security-оновлення, маленький workflow для ручної перевірки виглядає так:

name: next-security-watch
on:
  schedule:
    - cron: "0 9 3 11 *"
  workflow_dispatch:

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm outdated next

Це не автоматичний апгрейд – лише сигнал команді, що саме 3 листопада варто перевірити версії вручну. Автоматичне накатування security-патчів без читання advisory – погана ідея, особливо коли мова про фреймворк, який формує весь роутинг і рендеринг застосунку.

Чесні обмеження цього анонсу

Варто одразу зняти очікування: ні номерів CVE, ні переліку вразливих версій, ні опису конкретних сценаріїв атаки в анонсі немає. Усе це з’явиться тільки разом з релізом 3 листопада. Будь-які твердження на кшталт «вразливість у middleware» чи «проблема з кешем» зараз – це вже вигадка, а не факт із джерела, і довіряти таким заявам до публікації advisories не варто.

Також немає інформації про те, чи зачіпає реліз App Router, Pages Router, чи обидва; чи стосується це тільки серверної частини, чи й клієнтської збірки. Це нормально для advance notice – він існує саме для планування часу, а не для технічного аналізу.

Коли реагувати негайно, а коли можна почекати

Якщо твій застосунок обробляє публічний трафік і має критичні дані користувачів – плануй оновлення в перший же робочий день після релізу, одразу як з’являться advisories. Для внутрішніх адмінок чи прототипів з обмеженим доступом цілком реально взяти кілька днів на тестування перед апгрейдом – сім medium-вразливостей зазвичай не вимагають миттєвого хотфіксу вночі, на відміну від critical.

Якщо у вас використовується Cache Components у Next.js 16.4 або складна кастомна конфігурація кешування, варто закласти трохи більше часу на регресійне тестування після апгрейду – патчі безпеки іноді зачіпають і поведінку кешу, навіть якщо формально це не breaking change.

Фінальна порада проста: не чекай на сам реліз, щоб почати думати про процес. Перевір зараз, скільки часу у твоєї команди займає шлях від «вийшов патч» до «задеплоєно», і якщо це більше одного дня – це той технічний борг, який варто закрити до 3 листопада, а не після.