Node.js: релиз безопасности 11 ноября для 22.x/24.x/26.x

3 ноября 2026 года Node.js Project опубликовал pre-alert о релизе безопасности: новые версии для веток 22.x, 24.x и 26.x выйдут «11 ноября или вскоре после этой даты», старшая заявленная серьёзность исправлений — HIGH на всех трёх линиях разом. The Hacker News независимо осветил анонс на следующий день, подтвердив формулировку официального поста: команда фиксирует дату и уровень серьёзности, но не называет ни число уязвимостей, ни CVE, ни конкретные компоненты до выхода патча.

Что известно до релиза

Структура pre-alert у Node.js всегда одна и та же: отдельная страница в блоге проекта с датой будущего релиза и максимальной серьёзностью по каждой ветке, без деталей самой уязвимости. На этот раз под обновление попадают сразу все три поддерживаемые линии — активный LTS 22.x, текущий LTS-кандидат 24.x и свежая 26.x line, то есть практически любой прод на Node.js из числа актуальных версий. End-of-life ветки (20.x и старше) в анонсе отдельно помечены как «тоже уязвимы, но патча не получат» — для них единственный вариант закрыть проблему — переезд на поддерживаемую линию.

Почему детали не раскрывают заранее

Это стандартная практика проекта, а не секретность ради секретности: публикация CVE и описания бага одновременно с уязвимым кодом, но до выхода патча, дала бы атакующим фору на эксплуатацию раньше, чем админы успеют обновиться. Поэтому pre-alert отвечает только на вопрос «когда и насколько серьёзно», а разбор конкретных изменений появляется вместе с release notes фикса.

Что проверить до 11 ноября

• На каких версиях Node.js реально крутится прод — включая базовые образы в Docker, раннеры CI и serverless-рантаймы, которые часто забывают при аудите
• Не висит ли что-то на end-of-life ветке 20.x и ниже — для таких проектов патча не будет в принципе, релиз 11 ноября только подтвердит риск
• Есть ли регламент быстрого редеплоя: при HIGH-severity патче временной зазор между выходом фикса и обновлением прод-инфраструктуры — это и есть окно для эксплуатации

Подобные неожиданные security-релизы стабильно попадают в прод с задержкой именно потому, что у проекта нет человека, который держит график патчинга рантайма в регламенте, а не как разовую задачу после инцидента. На практике это закрывается тем же способом, что и обновления PHP или зависимостей: обновление рантайма — часть обычного сопровождения, а не отдельный аврал. Команде, которая ведёт разработку и сопровождение веб-приложений на регулярной основе, проще закладывать такие патчи в плановый цикл релизов, чем разбирать их постфактум после публикации CVE.