В этой статье разберёмся, что произошло, почему это опасно и какие последствия это несёт для разработчиков. Понимание этой ситуации критически важно для тех, кто использует Node.js в production-среде.

Как всё началось: история уязвимости

Уязвимость HTTP-клиента в Node.js имеет глубокие корни. Ещё в 2018 году выявили уязвимость CVE-2018-12116, которая позволяла внедрять управляющие символы через особенности кодировки latin1. Тогда команда разработчиков добавила защиту - проверку пути запроса в функции http.request, запретив символы вне диапазона от U+0021 до U+00FF.

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

Что именно может сделать злоумышленник

Последствия эксплуатации этой дыры зависят от того, как её использует атакующий. От простого внедрения заголовков до полного разделения HTTP-запросов - спектр атак довольно широк. Это означает, что пострадать могут приложения разного уровня сложности.

Вот основные сценарии, которые становятся возможными при эксплуатации:

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

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

Позиция Node.js: архитектурная особенность, а не ошибка

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

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

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

Почему это особенно опасно для вашего проекта

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

Приведём конкретный пример: если ваше приложение выполняет запрос к платежной системе для обработки платежей, атакующий теоретически может перенаправить этот запрос на свой сервер или добавить заголовок Authorization, направленный на другой сервис. Это создаёт серьёзный риск для конфиденциальности данных и целостности транзакций.

Особенно уязвимы приложения, которые:

• Обрабатывают пользовательский ввод при формировании URL для запросов
• Используют динамическое изменение path после инициализации ClientRequest
• Не имеют дополнительных уровней валидации между пользовательским вводом и HTTP-запросом
• Полагаются исключительно на встроенную защиту Node.js без дополнительной проверки

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

Что делать прямо сейчас

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

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

Другие уязвимости в Node.js: не только про HTTP

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

Особенное внимание заслуживает уязвимость в библиотеке vm2, которая позволяет выходить за пределы изолированной среды выполнения кода (CVE-2026-22709). Также найдены проблемы с обходом модели разрешений через символические ссылки и утечкой файловых дескрипторов в обработчиках TLS. Каждая из этих проблем представляет серьёзный риск для безопасности приложений.

В библиотеке node-tar обнаружена уязвимость обхода пути (CVE-2026-5xxx), которая влияет на распаковку архивов. Поскольку node-tar используется в самом npm и тысячах приложений, это представляет огромный риск для цепочки поставок ПО. Разработчики зависимостей, которые вы используете, могут быть скомпрометированы через эту лазейку.

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

Понимание логики разработчиков помогает найти объяснение их позиции. Они считают, что HTTP-клиент работает так, как задумано: свойства объекта доступны для изменения, потому что это может быть необходимо для некоторых легитимных сценариев. Навязывание неизменяемости свойств может нарушить обратную совместимость.

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

Это особенно цинично, учитывая, что проблема существует уже с 2018 года, была выявлена давно, но так и осталась незакрытой именно потому, что команда не считает её своей ответственностью.

На что обратить внимание при разработке

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

• Зафиксируйте версии зависимостей - используйте npm shrinkwrap или yarn.lock, чтобы избежать неожиданных обновлений уязвимых библиотек
• Проводите регулярные аудиты безопасности - команда npm проверяет зависимости, запускайте npm audit регулярно
• Оборачивайте http.request в собственный слой абстракции - это даёт вам контроль над валидацией и позволяет централизованно управлять безопасностью
• Не пересекайте HTTP-границы с пользовательским вводом напрямую - всегда валидируйте и санитизируйте данные
• Следите за security advisories - подпишитесь на уведомления безопасности Node.js и npm

Экосистемная дилемма: ответственность и реальность

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

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