Неделя патчей Node.js, Python и Next.js: мой порядок обновления на боевых серверах

За одну неделю вышли исправления безопасности у Node.js, Python и .NET, а Next.js выпустил бэкпорт багфиксов в поддерживаемую ветку. Если у вас свой сервер, сайт или интеграции, делать что-то нужно, и делать должен тот, кто за сервер отвечает, по порядку, который он знает заранее. Ниже что вышло и как обновляю я.

Что вышло

Node.js 21 октября выпустил три релиза безопасности: 26.12.1, 24.22.1 LTS и 22.23.4 LTS. 26.12.1 закрывает девять CVE, 24.22.1 восемь, 22.23.4 семь. В каждой линии есть уязвимости уровня High: в tls отказ от неканонических IP-адресов, в dns проверка входных данных resolve на нулевые байты и дыра в распаковке Brotli, CVE-2026-111497. Все три релиза обновляют список корневых сертификатов до NSS 3.131.1 и отказываются от цепочек с заблокированными публичными ключами. Причину в заметках не называют, но по датам это история с удостоверяющим центром eMudhra, о которой я писал несколькими днями раньше.

Python 25 октября выпустил 3.14.10 и 3.13.18. Оба релиза ускоренные и как раз из-за eMudhra: скомпрометированные ключи теперь блокирует модуль ssl, и обычный pip, включая обновление самого pip, защищён от атак с этими ключами, даже если pip ещё не обновляли. В 3.14.10 помимо этого около 120 исправлений от 63 участников и закрытая дыра в tarfile.tar_filter, CVE-2026-114583. Ветка 3.13 уже в режиме «только исправления безопасности» до октября 2028 года, установщиков для неё больше нет, только исходники.

Microsoft 25 октября выпустила внеплановые обновления .NET: 8.0.33, 9.0.22, 10.0.14 и .NET 11 RC3. Там та же CVE-2026-111497 в Brotli, что и у Node.js: переполнение буфера при распаковке с чтением или порчей памяти процесса. У .NET она срабатывает только там, где приложение распаковывает Brotli: в request decompression ASP.NET Core, в автоматической распаковке ответов HttpClient или через System.IO.Compression. Там же список действий, который годится не только для .NET: framework-dependent приложения обновляют рантайм и перезапускают, self-contained пересобирают, контейнеры пересобирают из обновлённых образов.

Next.js 23 октября выпустил 16.4.3. Это бэкпорт исправлений в активную LTS-ветку, без новых функций: в том числе URL шрифтов Google и трассы OpenTelemetry. Про безопасность там ничего не сказано. Мой сайт kononov.dev стоит на Next.js и Node.js 24, так что это обновление попадает в тот же цикл, что и Node.

Почему обновления откладывают

Возьмём сервисную компанию на 30 человек. У неё сайт, приложение для продавцов, телефония и парсеры документов, и всё это на одном сервере. Обновить Node.js значит перезапустить API, через который работают и сайт, и приложение. Днём звонят клиенты, ночью некому смотреть, и обновление откладывают на следующую неделю. Так проходит месяц, потом выходит следующая порция патчей, и перепрыгивать нужно две версии сразу.

Вывод: обновление откладывают, когда оно не отрепетировано. Если порядок известен и занимает час, его делают в тот же день.

Как обновляю я

Мои серверы: PDR-компания в США, где на Debian в Google Cloud работают API на Node.js, сайт, телефония и парсеры документов на Python; производственная компания, где расчёт заказов живёт на сервере с Node.js и Express под PM2; мой сайт на Next.js и Node.js 24 в Docker; и сервис «Кофе вместе» на том же общем сервере студии с 2 ГБ памяти. Порядок везде один.

Сначала инвентаризация. Я записываю, где какая версия рантайма: в системе, в каждом Docker-образе, в виртуальном окружении парсеров. Без этого списка нельзя сказать, закрыто ли у нас то, что закрыли в релизе.

Потом читаю, что исправили, и сверяю со своим кодом. Brotli распаковывается там, где HTTP-клиент принимает сжатые ответы, значит это касается API и всего, что ходит к внешним сервисам. Дыра в dns касается всего, что резолвит адреса из пользовательских данных. Так ясно, что обновлять первым.

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

Запуск. В «Кофе вместе» при обновлении старый экземпляр останавливается до запуска нового: двум копиям на 2 ГБ тесно, поэтому у контейнеров жёсткие лимиты памяти. Для парсеров я сначала проверяю, что в обработке ничего не висит, и только потом перезапускаю.

После запуска смотрю логи и проверяю один рабочий сценарий руками. Если что-то не так, возвращаю предыдущий образ. Когда порядок отрепетирован, вся неделя патчей укладывается в часы.

Что я бы сделал на вашем месте

Спросить у того, кто ведёт сервер, какие версии Node.js, Python или .NET у вас стоят и где именно. Если ответа нет за день, это первая проблема.

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

Попросить, чтобы обновление шло через пересборку образов и чтобы предыдущая версия оставалась под рукой.

Записать порядок один раз. В следующую такую неделю он понадобится снова, и тогда на обновление уйдёт час.

О том, как фоновые задачи переживают перезапуск: статья Воркеры: фоновые задачи и повторные попытки. Инфраструктура, которую можно выпускать и восстанавливать: DevOps и инфраструктура. Сервер и API, о которых речь, описаны в кейсе технического партнёрства с PDR-компанией и на странице про собственный API для нескольких приложений. Из близких обзоров: PHP2Shell и проверка своих серверов, радиус поражения обновления и бэкап, который никто не восстанавливал; раньше я писал про выпуск Docker-приложения с возвратом версии. Если у вас есть сервер, а порядка обновления нет, расскажите, что на нём стоит, и я предложу, с чего начать. Обсудить задачу.