🚨 Срочный апдейт по безопасности в Node.js

Node.js выпустил срочный security-релиз, который закрывает опасную уязвимость отказа в обслуживании (DoS). И это хороший повод обратить внимание всем backend-разработчикам, а не только JS-сообществу.

Михаил Поливаха, эксперт сообщества Spring АйО, пояснил в чём проблема и почему она касается в том числе Java разработчиков.

В чем суть проблемы?

В ряде Node.js-приложений сервер мог падать целиком от одного запроса. Без логов. Без обработки ошибок. Без возможности мониторинга причин.

А всё дело в том, что рантайм Node-ы в рамках ассинхронного контекста (Promise или async/await) не контролировал глубокую или даже бесконечную рекурсию и позволял ей положить весь рантайм.

В результате:

🔵ошибка не перехватывалась кодом
🔵не доходила до глобальных обработчиков
🔵сервер падал с ошибкой

Кого это затронуло сильнее всего?

🔵Приложения на React / Next.js
🔵Любые системы с APM (Datadog, New Relic, OpenTelemetry)
🔵Большинство продакшн-Node.js-сервисов по умолчанию

Что сделали разработчики Node.js?

🔵Исправили поведение: теперь ошибка возвращается в код, а не убивает процесс
🔵Выпустили security-релиз для всех актуальных веток
🔵Отдельно подчеркнули, что это больше смягчение, а не гарантия безопасности

Почему это важно для Spring разработчика?

А потому, что контролировать рекурсию на основе входных данных нужно всегда, и Spring Data, например, в своё время фиксила такую дыру у себя тоже в рамках Property Path Traversal.

Главный вывод

Если глубина рекурсии, размер и строение входных структур или объём ресурсов могут контролироваться пользователем — нужно вводить явные ограничения, как это сделала Spring Data.

Это справедливо для Node.js, для Java / Spring, для любых backend-систем.

📌 Помним, что DoS-уязвимости часто рождаются не в бизнес-логике, а на стыке рантайма, инфраструктуры и удобных абстракций.

🔗 Подробнее: https://nodejs.org/en/blog/vulnerability/january-2026-dos-mitigation-async-hooks