# Next.js готує security release 3 листопада: сім medium-вразливостей і що робити зараз

> Next.js анонсував плановий security release на 3 листопада 2026 – сім medium vulnerabilities. Розбираємо, що відомо, чого ще немає, і як підготуватись до апгрейду заздалегідь.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-10-31
- Категорія: React і Frontend
- Canonical: https://cookiesoftware.io/blog/nextjs-november-2026-security-release

---
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](/blog/nodejs-october-2026-security-release). Корисно порівняти обидва підходи – екосистема явно рухається в бік публічних попереджень за кілька днів до релізу.

## Що саме анонсував 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` для ключових пакетів:

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

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

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

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

```yaml
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](/blog/nextjs-16-4-cache-components) або складна кастомна конфігурація кешування, варто закласти трохи більше часу на регресійне тестування після апгрейду – патчі безпеки іноді зачіпають і поведінку кешу, навіть якщо формально це не breaking change.

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