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

Как всё начиналось: история с 2018 года

Всё началось с уязвимости CVE-2018-12116, которая позволяла внедрять управляющие символы через особенности кодировки latin1. Разработчики тогда добавили проверку пути запроса в http.request, запретив символы вне диапазона \u0021—\u00ff. Звучало как надёжное решение — проверка срабатывала в момент создания объекта ClientRequest.

Но была одна проблема: после создания запроса свойство path оставалось обычным изменяемым полем без дополнительной валидации. Это было логично с точки зрения архитектуры — зачем ограничивать возможности разработчика, если защита уже установлена при создании? Вот только это создало новую уязвимость, которая ждала, пока её обнаружат.

Ключевые моменты того периода:

• Проверка срабатывала только один раз при создании объекта
• После этого разработчик мог свободно менять значение path
• Никакой валидации при изменении свойства не было

Что нашли исследователи в 2026 году

Мартино Спаньоло (ник r3verii) обнаружил способ обойти ту самую защиту. Исследователь выяснил, что можно изменить свойство path после создания объекта ClientRequest, тем самым провести атаку на HTTP-клиент базовой логикой уязвимости разделения запросов.

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

Три сценария эксплуатации:

• Лёгкий вариант: внедрение дополнительных HTTP-заголовков, подмена Host или Authorization
• Средний вариант: закрытие заголовков и добавление тела запроса, изменение семантики исходного обращения
• Опасный вариант: полноценное разделение запроса, когда сервер получает два самостоятельных HTTP-обращения вместо одного

Реакция команды Node.js и дебаты

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

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

Почему это стало проблемой:

• Разработчики ожидают, что валидация останется актуальной на протяжении жизни объекта
• Для многих библиотек изменение path — нормальная операция
• Масштаб экосистемы означает, что уязвимость касается миллионов приложений
• Рабочие примеры эксплуатации существуют и доступны

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

Это не единственная серьёзная проблема в экосистеме. В начале 2026 года команда Node.js выпустила серию обновлений, которые закрывали несколько критических уязвимостей. Разработчикам было рекомендовано обновиться на исправленные версии: 20.20.0, 22.22.0, 24.13.0 и 25.3.0.

Особое внимание привлекла уязвимость CVE-2025-59466, которая позволяла проводить атаки типа Denial-of-Service (DoS). Эта проблема могла серьёзно повлиять на производительность и надёжность приложения, особенно во время пиков нагрузки.

Свежие критические уязвимости:

• CVE-2026-21636: обход модели разрешений через непроверенные подключения Unix Domain Socket (UDS), CVSS 10.0
• CVE-2026-22709: в библиотеке vm2 найдена уязвимость с оценкой 9.8 CVSS, позволяющая обходить sandbox и выполнять код на хосте
• CVE-2025-59466: уязвимость DoS, которая может привести к замедлению отклика приложения до предела

Как это защитить и на что обратить внимание

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

Прежде всего, держите свои зависимости в актуальном состоянии. Регулярно запускайте npm audit, чтобы выявлять потенциальные проблемы на ранних стадиях разработки. Но это только часть решения — нужна комплексная стратегия.

Практические шаги для защиты:

• Регулярно обновляйте Node.js и все зависимости до последних исправленных версий
• Используйте npm audit и npm audit fix для проверки известных уязвимостей
• Внедрите CI/CD с автоматическими проверками безопасности на каждый коммит
• Не изменяйте критические свойства объектов после их инициализации без необходимости
• Проверяйте исходный код библиотек, если они работают с сетевыми запросами
• Используйте инструменты статического анализа кода (SAST) для поиска потенциальных проблем

Вопрос о ответственности и коммьюнити

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

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

На что стоит обратить внимание:

• Если валидация срабатывает только при создании объекта, это может быть уязвимостью
• Разработчикам часто нужно менять параметры запросов, это нормальное использование API
• Масштаб экосистемы Node.js означает, что даже небольшие проблемы имеют огромное влияние
• Важно следить за дебатами в сообществе, а не только на официальные заявления

Что это значит для будущего

История с Node.js напоминает нам, что безопасность — это не только проблема разработчиков фреймворка, но и наша с вами ответственность. Когда команда говорит, что это особенность, а не баг, это не значит, что проблема исчезла. Это значит, что нам нужно защищаться самостоятельно.

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