# Node.js готує security release 21 жовтня: що зробити до появи CVE

> Node.js анонсував security releases для 26.x, 24.x і 22.x із найвищою severity HIGH. Деталей ще немає – і саме тому зараз найкращий момент перевірити свій update-процес. Практичний pre-release checklist.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-10-15
- Категорія: Backend і System Design
- Canonical: https://cookiesoftware.io/blog/nodejs-october-2026-security-release

---

Node.js Project [попередив](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases): у середу 21 жовтня 2026 (або невдовзі після) вийдуть security releases для лінійок 26.x, 24.x і 22.x. Найвища severity серед виправлень – HIGH, причому для кожної з трьох ліній. Деталі вразливостей до релізу закриті – і це нормальна практика responsible disclosure. Паніки це не вимагає; вимагає підготовки. Нижче – checklist, який варто пройти за тиждень до патчу, а не вночі після нього.

## Що відомо (і що чесно невідомо)

Відомо: три лінії отримають оновлення, найвища severity – HIGH, дата – 21 жовтня або трохи пізніше. На момент написання (15.10) реліз ще не вийшов.

Невідомо: які саме вразливості, які конфігурації exploitable, чи стосується це твого коду взагалі. Тому будь-хто, хто сьогодні каже «ви вразливі» або «вас це не стосується», – ворожить. Правильна security-комунікація не створює паніку. Вона створює readiness.

Хороший інженерний тест, який ця новина ставить руба: **якщо завтра о 10:00 виходить critical Node patch – скільки часу потрібно від release до production?** Якщо відповідь «не знаємо» – оце і є вразливість, яку можна виправити вже зараз, без жодного CVE.

## Checklist до 21 жовтня

### 1. Знайди всі Node-рантайми

Не тільки production-застосунок. Node живе у більшій кількості місць, ніж здається:

- Docker-образи сервісів (включно з `FROM node:…` у build-стадіях);
- CI-ранери й GitHub Actions (`actions/setup-node` – яку версію тягне?);
- serverless-функції (runtime у Vercel/AWS налаштовується окремо від package.json);
- cron-джоби й internal-скрипти на серверах;
- локальні тулінги, які ходять у прод (migration-скрипти, адмінські CLI).

Швидка інвентаризація по репозиторіях:

```bash
grep -rn "FROM node" --include="Dockerfile*" .
grep -rn "node-version" .github/workflows/
cat .nvmrc package.json | grep -A1 engines
```

### 2. Зрозумій свою release line

Патчі отримають 26.x, 24.x і 22.x. Якщо твій прод на 20.x чи старше – security-патчу для тебе **не буде**: EOL-лінія означає, що нормальний вихід – це міграція, і краще планова цього тижня, ніж аварійна наступного. (Бонус міграції на 26.x – [Temporal уже ввімкнений за замовчуванням](/blog/nodejs-temporal-api).)

### 3. Перевір, що оновлення прогониться автоматично

Оновлення base image має тягнути за собою повний прогін: unit, integration, E2E, smoke. Якщо бамп версії Node у Dockerfile вимагає ручних танців – зараз саме час написати той один workflow, якого бракує. Про те, щоб CI сам був захищений від сюрпризів, – окрема свіжа тема: [lockfiles для GitHub Actions](/blog/github-actions-lockfiles).

### 4. Підготуй rollback

Security update не означає «деплой без перевірки». Патч-релізи Node зрідка, але ламають нативні модулі чи поведінку країв. План Б простий: попередній образ під рукою, одна команда відкату, і ти знаєш, хто її виконує о другій ночі.

### 5. Після disclosure – advisory, а не Twitter

Коли реліз вийде, прочитай сам advisory: який компонент, який вектор, які передумови. «HIGH» у заголовку може означати «exploitable лише з увімкненим X», якого в тебе немає, – або навпаки, вдарити точно у твій setup (як-от [нещодавній kernel-дефект у мережевому стеку](/blog/vercel-sandbox-million-dollar-challenge), що зачіпав будь-кого з мережею). Рішення про терміновість деплою ухвалюється по advisory, не по переказах.

### 6. Бонус: обмеж blast radius уже сьогодні

Частина вразливостей Node стосується файлової системи, child_process чи мережі. [Permission Model](/blog/nodejs-permission-model) не замінить патч, але процес, якому технічно заборонено читати `~/.ssh`, перетворює деякі «HIGH» саме для тебе на «неприємно, але не катастрофа». Defense in depth працює і тут.

## Пожежне навчання без пожежі

Проведи цього тижня «пожежне навчання» без пожежі:

1. Склади список усіх місць, де живе Node (пункт 1 вище) – письмово, у repo.
2. Зроби тестовий бамп base image у staging і засічи час від зміни рядка в Dockerfile до зеленого deploy.
3. Запиши отриману цифру в README чи runbook. 21 жовтня порівняєш план із реальністю – і це буде найчесніший аудит твого deploy-процесу за рік.

## Чого не робити перед патч-днем

- **Чекати CVE, щоб почати.** Після disclosure рахунок іде на години – вікно, коли exploit уже публічний, а твій прод ще ні.
- **Оновити прод і забути CI/cron/скрипти.** Атакують найслабший runtime, а не найпомітніший.
- **«Ми за WAF/у приватній мережі, нас не стосується».** Можливо. Але це висновок, який можна зробити лише після читання advisory, не до.
- **Оновлення без тестів «бо security».** Поспіх без перевірки просто міняє один клас інцидентів на інший.
- **Сидіти на EOL-лінії «ще трошки».** «Трошки» закінчується рівно в момент виходу патчу, якого для тебе немає.

Поки деталі не опубліковані, не можна чесно сказати, чи ти вразливий. Але можна чесно сказати, чи ти **готовий**. Перше від тебе не залежить. Друге – повністю.