Коротко: 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 сервіси
Пріоритет:
- Публічні API/бекенди з інтернет-доступом.
- Сервіси з auth/session/payment.
- Внутрішні утиліти і воркери.
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-міграцію в пріоритетний план.
Офіційні джерела: