11 ноября 2026 года вышла Node.js 26.13.1 — обновление безопасности для ветки длительной поддержки Lithium. Разработчики устранили 16 уязвимостей, семь из которых имеют высокий уровень опасности. Некоторые ошибки позволяли удалённо останавливать сервер, получать фрагменты чужих данных или обходить проверку клиентских сертификатов при определённых настройках TLS.
Ошибки HTTP/2 позволяли завершать серверный процесс и расходовать его память
Один из наиболее опасных сценариев связан с обычным HTTP/2-запросом, на который сервер отвечает до завершения загрузки данных. Из-за ошибки при очистке соединения процесс Node.js — среды для запуска JavaScript-приложений — мог аварийно завершиться: удалённому клиенту не требовалась авторизация. Уязвимость получила идентификатор CVE-2026-123863 и высокий уровень опасности.
Другие проблемы возникали при разрыве соединений и отмене загрузок. Например, CVE-2026-123875 позволяла вызвать сбой сервера, если приложение отдавало файлы через respondWithFile() или respondWithFD(), а клиент прерывал передачу. Соседняя уязвимость CVE-2026-123874 затрагивала тот же сценарий при незавершённой записи в сетевое соединение: обращение к уже освобождённому объекту могло повредить память процесса.
Была и менее заметная проблема. При определённой последовательности закрытия HTTP/2-сессии (CVE-2026-123865) сервер удерживал память и ресурсы уже закрытого соединения. Повторение таких запросов постепенно расходовало ресурсы. Отдельное исправление CVE-2026-123868 заставило учитывать входящие данные, ожидающие обработки, в лимите maxSessionMemory: раньше эта очередь могла увеличиваться без отражения в указанном ограничении.
Чем это отличается от обычного сбоя приложения? Указанные ошибки находились внутри механизмов обработки сетевых соединений Node.js. Даже корректный прикладной обработчик не всегда мог предотвратить завершение процесса или накопление ресурсов.
Через HTTPS при определённых условиях могли утекать чужие запросы и секреты
Уязвимость CVE-2026-123864 затрагивала обработку зашифрованного HTTPS-трафика. При определённом порядке операций с запросом повторный вход в разборщик HTTP-запросов мог привести к чтению посторонних областей памяти. В официальном описании среди потенциально доступных данных названы запросы других клиентов и закрытые TLS-ключи.
Для проявления ошибки требовался конкретный сценарий: приложение вызывало res.flushHeaders() до окончания тела входящего запроса, затем отправляло непустой ответ, а в приложении существовал маршрут, который отражал или сохранял тело запроса. Обычный незашифрованный модуль node:http этой уязвимости не затрагивался.
Ещё одно исправление касается серверов с mTLS, где для доступа клиент предъявляет собственный сертификат. При использовании разных правил сертификатной авторизации для разных доменных имён ошибка CVE-2026-123872 позволяла изменить имя сервера во время повторного согласования TLS 1.2 и обойти более строгую проверку. В Node.js 26.13.1 закрыли несколько путей изменения имени сервера, включая повторное использование TLS-сессий.
Отдельно устранена CVE-2026-126051: удалённый клиент мог вызвать аварийное завершение TLS-сервера, использовавшего определённые обработчики рукопожатия, например SNICallback, OCSPRequest или resumeSession. Уязвимость затрагивала конфигурации, где эти обработчики действительно были подключены.
Ошибка в настройке прокси могла раскрыть логин и пароль в журнале
Проблема CVE-2026-123871 проявлялась при некорректно заданном адресе прокси. В отдельных сообщениях ERR_PROXY_INVALID_CONFIG Node.js выводил исходный URL вместе с учётными данными. Если ошибки записывались в журналы контейнеров, системы мониторинга или отчёты о сбоях, пароль мог оказаться доступен людям и сервисам, имеющим доступ к этим записям.
Поправка дополняет прежнее исправление похожей утечки: тогда скрыли данные из ProxyConfig.href, но несколько путей формирования сообщений об ошибке сохранили исходный URL.
В области контроля доступа исправили и CVE-2026-123829. На Windows и macOS рекурсивное слежение за каталогами через fs.watch() в режиме ограниченных разрешений могло сообщать имена файлов во вложенных папках, чтение которых было запрещено. Содержимое файлов эта ошибка не раскрывала.
Какие приложения затрагивает обновление Node.js 26.13.1
Большая часть описанных проблем касается серверов, которые используют встроенные механизмы HTTP/2, HTTPS и TLS Node.js. Конкретный риск зависит от того, какие протоколы обрабатывает сам процесс, как устроены маршруты приложения, используются ли клиентские сертификаты, файловые ответы и повторное использование соединений. Если шифрование и HTTP/2 завершаются на отдельном обратном прокси, набор доступных извне путей к уязвимым механизмам Node.js меняется.
Есть и клиентские сценарии: например, в CVE-2026-123877 исправлена возможность некорректно повторно использовать TLS-сессию в https.Agent при различающихся настройках доверия к сертификатам. Следовательно, сфера изменений шире, чем публичные веб-серверы.
В тот же день проект выпустил исправленные версии для других поддерживаемых веток:
- Node.js 26.13.1 — ветка Lithium (LTS);
- Node.js 24.22.3 — ветка Krypton (LTS);
- Node.js 22.23.5 — ветка Jod (LTS).
Состав затронутых уязвимостей различается между ветками. Поэтому номер исправленной версии зависит от того, на какой линии Node.js работает приложение. В сборке 26.13.1 обновились и встроенные компоненты, включая llhttp до 9.4.4 и undici до 8.12.4.
После перехода Lithium на LTS акцент сместился на безопасность
28 октября 2026 года Node.js 26.13.0 перевёл ветку Lithium в режим длительной поддержки. Тогда изменение в основном касалось статуса выпуска и служебных метаданных. Версия 26.13.1, появившаяся через две недели, уже меняет обработку сетевых соединений, освобождение памяти и проверку сертификатов. Поддержка Node.js 26 запланирована до конца апреля 2029 года.
Ноябрьский набор исправлений показывает несколько разных классов риска в одном серверном окружении: отказ в обслуживании, утечку памяти и данных, обход правил TLS и раскрытие учётных данных через журналы. Для каждого из них условия проявления различаются, поэтому наличие уязвимой версии само по себе ещё не описывает конкретный путь атаки на приложение.
