Node.js security patch day: що оновити в 20.x/22.x/24.x/25.x і як не залетіти в EOL

Коротко: 24 березня Node.js офіційно оголосив security releases для 25.x, 24.x, 22.x і 20.x: 2 High + кілька Medium/Low. Кожен такий Security release — це прямий сигнал закрити відомі ризики без відкладань. Якщо у вас продакшн на Node — це не новина «на потім». Мінімальна правильна дія: перевірити, чи ваша лінійка ще підтримується, оновити до актуального патча і окремо прибрати EOL-інстанси.

Що саме важливо в цьому security-вікні

За офіційним анонсом, уражені всі підтримувані на момент релізу лінійки (20/22/24/25) з різним набором уразливостей. Також Node.js прямо нагадує: EOL-версії завжди в зоні ризику, бо для них security-фікси вже не виходять.

Практичний висновок: навіть якщо «нічого не впало», це все одно технічний борг, який росте щодня.

Які лінійки зараз у грі

За офіційним release schedule:

Лінійка	Статус	EOL
25.x	Current	2026-06-01
24.x	Active LTS (Krypton)	2028-04-30
22.x	Maintenance LTS (Jod)	2027-04-30
20.x	Maintenance LTS (Iron)	2026-04-30

Що це означає для команд:

• 24.x — найкомфортніша ціль для більшості продакшн-сервісів.
• 20.x — ще підтримується, але вже близько до завершення життєвого циклу.
• 25.x — для тих, хто свідомо живе на Current.

30-хвилинний playbook без хаосу

1) Зробіть інвентаризацію реальних версій

Не довіряйте лише package.json — перевірте, що реально крутиться на серверах/контейнерах:

node -v
npm -v

Для Docker-сервісів — подивіться базовий образ (FROM node:...).

2) Автоматично підтягніть актуальні патчі по лінійках

Краще брати цільові версії не «з голови», а з офіційного index.json:

curl -fsSL https://nodejs.org/dist/index.json | jq -r '
  map(select(.version|test("^v(20|22|24|25)\\.")))
  | group_by(.version|split(".")[0])
  | map({line: (.[0].version|split(".")[0]|ltrimstr("v")) + ".x", latest: .[0].version, date: .[0].date})
  | sort_by(.line)
  | .[] | "\(.line) -> \(.latest) (\(.date))"'

3) Оновіть спочатку high-risk сервіси

Пріоритет:

1. Публічні API/бекенди з інтернет-доступом.
2. Сервіси з auth/session/payment.
3. Внутрішні утиліти і воркери.

4) Проженіть мінімальний Smoke test

Після апгрейду:

• сервіс стартує без попереджень/крашів;
• TLS/HTTP-з’єднання працюють;
• CI тести проходять;
• ключові user flows відповідають очікувано;
• в логах немає нових критичних помилок.

5) Закрийте EOL-ризики окремим таском

Якщо десь лишилися старі гілки (типу 18.x і нижче), це має бути окремий пріоритетний migration ticket із дедлайном, а не «коли буде час».

Типові помилки після security-анонсу

• Оновили тільки один сервіс, бо він “найважливіший”. Наслідок: приховані уразливості лишаються в інших сервісах.

• Застрягли на “підтримуваній, але майже EOL” лінійці без плану міграції. Наслідок: через кілька тижнів/місяців ви вже без security-підтримки.

• Не зафіксували процес перевірки оновлень. Наслідок: те саме повторюється при кожному patch day.

Що зробити, щоб це не було разовим героїзмом

Мінімальна рутина для команди:

• щотижнева перевірка security-апдейтів;
• щомісячний аудит фактичних Node-версій у продакшні;
• правило: EOL-версії не допускаються в нові деплої;
• короткий runbook «оновлення + rollback» у внутрішній документації.

Висновок

Node.js security patch day — це не «ще один реліз», а сигнал швидко закрити відомі дірки. Найкраща тактика: автоматично визначити актуальні патчі, оновити підтримувані лінійки сьогодні, і паралельно винести EOL-міграцію в пріоритетний план.

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

• https://nodejs.org/en/blog/vulnerability/march-2026-security-releases
• https://github.com/nodejs/release#release-schedule
• https://nodejs.org/dist/index.json
• https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule
• https://nodejs.org/en/blog/release/v25.8.1