Почему это важно? Потому что от Node.js зависят миллионы веб-приложений, API и инструментов сборки по всему миру. Когда основное средство разработки содержит архитектурный порок, от этого страдают все, кто его использует. Давайте разберёмся, что произошло и почему никто не может просто взять и всё исправить.

Что именно произошло с Node.js

В экосистеме Node.js обнаружили уязвимость, связанную с базовой логикой HTTP-клиента. Проблема заключается в механизме, который открывает возможность внедрения заголовков и формирования второго запроса в рамках одного соединения. Звучит сложно, но суть простая: злоумышленник может выдать себя за другого пользователя, перехватить данные или полностью изменить смысл запроса.

Эта уязвимость уходит корнями в 2018 год. Тогда разработчики уже боролись с похожей проблемой (CVE-2018-12116), которая позволяла внедрять управляющие символы через особенности кодировки latin1. Они добавили проверку пути запроса, запретив символы вне диапазона \u0021—\u00ff. Казалось, что защита сработала. Но оказалось, что защита срабатывала только в момент создания объекта ClientRequest, а после этого свойство path оставалось обычным изменяемым полем без дополнительной валидации.

Это типичная ошибка архитектуры: когда критичные параметры можно менять после инициализации, без переповтора проверок безопасности.

Почему Node.js отказался всё исправлять

Исследователь Мартино Спаньоло под ником r3verii опубликовал детальный разбор уязвимости и отправил отчёт в Node.js через программу HackerOne. Ответ был неожиданным: команда Node.js заявила, что поведение соответствует текущей логике работы и не считается уязвимостью. По их позиции, ответственность лежит на библиотеках, которые позволяют менять path после создания запроса.

Основной аргумент Node.js - это не наша ошибка, это проблема в коде ваших библиотек. Но исследователь не согласился и указал на масштаб экосистемы: он проверил популярные библиотеки и выявил семь проектов с незащищённым промежутком TOCTOU (Time-of-Check-Time-of-Use). Среди уязвимых проектов оказались node-http-proxy, http-proxy-middleware и другие широко используемые инструменты.

Сложность в том, что такое архитектурное решение невозможно быстро переделать. Это потребовало бы массированных изменений во всём коде Node.js и несовместимости с миллионами приложений, которые на него полагаются.

Какие именно атаки становятся возможными

Последствия эксплуатации этой уязвимости зависят от того, как её применить. Давайте разберём от простого к сложному:

Внедрение заголовков. В самом простом варианте злоумышленник внедряет дополнительные HTTP-заголовки. Например, меняет Host или Authorization. Приложение получит запрос с ненужными или поддельными заголовками и может неправильно обработать данные. Это позволяет перехватить сессию или выдать себя за другого пользователя.

Изменение семантики запроса. Более серьёзный сценарий позволяет закрыть заголовки и добавить тело запроса, полностью изменив смысл исходного обращения. Если приложение отправляет на сервер форму с защитой от CSRF, злоумышленник может переписать параметры и выполнить неавторизованное действие.

Полное разделение запроса. Самый опасный вариант приводит к тому, что сервер получает два самостоятельных HTTP-обращения вместо одного. Это называется HTTP Request Smuggling - одна из самых коварных уязвимостей, потому что приложение видит один запрос, а сервер обрабатывает два.

Рассмотрим конкретный пример. Допустим, приложение отправляет запрос для перевода денег со счёта пользователя на счёт благотворительной организации. Злоумышленник может внедрить дополнительный запрос, который переводит деньги на его собственный счёт, и всё это произойдёт за спиной приложения.

Другие критические уязвимости Node.js в 2026 году

Это не единственная проблема, с которой столкнулась экосистема Node.js в последние месяцы. Есть и другие серьёзные уязвимости:

CVE-2026-21636. Уязвимость, связанная с обходом модели разрешений через непроверенные подключения Unix Domain Socket (UDS). Получила максимальную оценку по шкале CVSS 3.1 - 10.0. Суть проблемы в недостатках контроля доступа в механизме безопасности Node.js. Модель разрешений, призванная ограничивать возможности приложений, может быть обойдена через специально сконфигурированные подключения к Unix-сокетам. В результате злоумышленник получает возможность выйти за пределы песочницы и выполнить произвольные команды с высокими привилегиями.

CVE-2026-22709 в библиотеке vm2. Критическая уязвимость в библиотеке vm2, которую часто используют для запуска недоверенного JavaScript-кода в Node.js. Проблема получила оценку 9.8 по CVSS. Успешная эксплуатация позволяет выполнить произвольный код на хост-системе. Все версии vm2 ниже 3.10.2 уязвимы к атаке. Ошибка кроется в механизме обработки Promise - асинхронных операций JavaScript. Библиотека корректно фильтрует обратные вызовы для собственных объектов localPromise, но не делает этого для глобальных Promise, которые возвращают асинхронные функции. Это позволяет злоумышленнику заставить код выполнить команды за пределами песочницы. Разработчик опубликовал демонстрационный код эксплуатации, так что проблему легко воспроизвести.

CVE-2025-59466. Уязвимость, которая привлекла внимание благодаря своему потенциалу позволить атаки Denial-of-Service (DoS). Последствия различаются в зависимости от передаваемых данных. В простейшем варианте медленнеет приложение, в худшем - оно полностью падает.

CVE-2025-27209. Классифицируется как HashDoS - возможность вызвать отказ приложения через создание множественных коллизий хешей. Это означает, что специально подготовленные данные могут заставить сервер тратить все ресурсы на обработку.

Кто в опасности и что нужно делать

Потенциальный масштаб воздействия оценивается как очень высокий. Node.js повсеместно используется для создания серверных приложений, REST API и инструментов сборки. Если вы разработчик, используете Node.js или работаете с приложениями на его основе - вы в зоне риска.

Для тех, кто серьёзно относится к безопасности, есть несколько рекомендаций:

• Обновляться немедленно. Используйте исправленные версии Node.js: 20.20.0, 22.22.0, 24.13.0 и 25.3.0, которые включают ключевые исправления против выявленных уязвимостей.
• Проверьте зависимости. Если вы используете vm2, обновитесь минимум до версии 3.10.3, где исправлена CVE-2026-22709. Простота эксплуатации этой уязвимости делает обновление критичным.
• Пересмотрите валидацию. Если вы создаёте HTTP-клиента или используете библиотеки, которые позволяют менять параметры запроса после создания, добавьте переповтор валидации перед отправкой.
• Мониторьте трафик. Атаки типа HTTP Request Smuggling сложно обнаружить автоматически, но можно настроить логирование всех изменений параметров запроса.
• Оценивайте риски. Не всем приложениям нужна максимальная безопасность. Если ваше приложение критично для бизнеса, нужна более тщательная защита. Если это демо-проект - можно дождаться стабильной версии исправления.

Архитектура как судьба

Самая важная деталь - это то, что Node.js отказался исправлять уязвимость на уровне архитектуры. Команда разработчиков не видит это как их проблему. Это не ошибка, это особенность, и менять её не собираются.

Это поднимает большой вопрос о том, как должна работать безопасность в крупных фреймворках и платформах. Если основной инструмент позволяет делать опасные вещи, кто несёт ответственность - создатель инструмента или разработчик, который его использует? Текущая позиция Node.js - разработчик сам за это ответственен. Но когда проблема затрагивает миллионы приложений, ответственность размывается.

Это не означает, что Node.js внезапно стал небезопасным. Это означает, что нужно быть внимательнее при использовании, чаще обновляться и тщательнее проверять собственный код. Архитектурные проблемы невозможно решить единоразово - их приходится обходить постоянно.