Внеплановый патч .NET: уязвимость в Brotli и две недели до конца поддержки .NET 8 и 9

Что именно исправили

Главная из четырёх уязвимостей выпуска — CVE-2026-111497. Это запись за пределы буфера (CWE-787) в декодере Brotli, который .NET использует для распаковки. В бюллетене Microsoft на GitHub ей присвоена оценка CVSS 8.1. Специально собранный поток Brotli позволяет атакующему без аутентификации читать или портить память процесса. Возможные последствия — утечка данных, отказ в обслуживании или повышение привилегий.

Уязвим не код .NET как таковой, а библиотека Brotli версий с 1.0.3 по 1.2.0. Исправленные выпуски 1.2.1, 1.1.1 и 1.0.10 вышли 21 октября, и в тот же день патчи получил Node.js, где та же ошибка давала удалённое выполнение кода через fetch() и парсеры тела запросов Express 5 (разбор TuxCare). В .NET библиотека встроена в рантайм, поэтому исправление пришло через обновление самой платформы.

В тот же выпуск вошли ещё три исправления. CVE-2026-114148 — небезопасные владельцы файлов в tar-архивах .NET для Linux, через которые локальный пользователь мог подменить файлы и поднять привилегии. CVE-2026-70197 (повреждение памяти в SocketAsyncEventArgs) и CVE-2026-102870 (отладчик Blazor WebAssembly) выпущены повторно: исправления от 13 октября оказались неполными.

Кого это касается, а кого нет

Ошибка срабатывает только там, где приложение само распаковывает Brotli-данные из недоверенного источника. По данным Microsoft, это три сценария:

• распаковка тела запроса в ASP.NET Core (AddRequestDecompression), если среди провайдеров остался br;
• автоматическая распаковка ответов в HttpClient или HttpClientHandler, если в AutomaticDecompression включён Brotli. Значение DecompressionMethods.All его тоже включает;
• прямые вызовы BrotliStream и BrotliDecoder из System.IO.Compression на внешних данных: загрузки файлов, ответы партнёрских API, содержимое очередей.

По умолчанию ни ASP.NET Core, ни HttpClient Brotli не распаковывают. Сжатие ответов сервером (UseResponseCompression) тоже не уязвимо: там данные упаковываются, а не разбираются. .NET Framework 4.x под удар не попадает, так что классические сайты на Web Forms и десктоп на старом фреймворке это обновление не затрагивает. Остальных угроз для них это не отменяет: о них мы писали в материале об укреплении старого сайта на ASP.NET Web Forms.

Как быстро проверить свой проект

Сначала посмотрите, какие рантаймы стоят на серверах и в образах контейнеров. Исправленные версии — 8.0.33, 9.0.22, 10.0.14 и 11.0 RC3. Всё, что ниже, нужно обновлять.

dotnet --list-runtimes
rem Microsoft.AspNetCore.App 8.0.33 и Microsoft.NETCore.App 8.0.33 - исправлено
rem 8.0.32 и ниже - обновить

rem где в коде включается распаковка Brotli
findstr /s /n /i "BrotliStream BrotliDecoder AddRequestDecompression AutomaticDecompression DecompressionMethods.All" *.vb *.cs

Если обновиться прямо сейчас нельзя (заморозка релиза, согласования с заказчиком), Microsoft предлагает временную меру: не распаковывать Brotli-данные от недоверенных источников. На практике это сужение списка методов в клиенте и удаление провайдера br на сервере:

Imports System.Net
Imports System.Net.Http

' было: AutomaticDecompression = DecompressionMethods.All (включает Brotli)
Dim handler As New HttpClientHandler With {
    .AutomaticDecompression = DecompressionMethods.GZip Or DecompressionMethods.Deflate
}
Dim client As New HttpClient(handler)

' ASP.NET Core: распаковка запросов без Brotli
builder.Services.AddRequestDecompression(
    Sub(o) o.DecompressionProviders.Remove("br"))

Почему для legacy-команд это не обычный вторник

Большинство команд, которые за последние два года уходили с VB6, Web Forms или старого WinForms, выбирали .NET 8 как LTS-версию, о чём шла речь в нашем разборе переноса WinForms на VB.NET в .NET 8. Срок поддержки .NET 8 и .NET 9 заканчивается 10 ноября 2026 года (политика поддержки .NET). Выходит, что внеплановый патч — одно из последних исправлений безопасности, которые эти версии получат. Следующая подобная уязвимость после 10 ноября закрыта для них уже не будет.

Для проектов на .NET 8 решение уже не сводится к тому, ставить патч или нет. Нужен план перехода на .NET 10 (текущая LTS) с понятными сроками. Технически переход 8 → 10 обычно проще, чем было 4.8 → 8, но в legacy-коде он упирается в те же места: устаревшие NuGet-пакеты без новых версий, самописные обёртки над COM и сборки, которые никто не пересобирал годами. С чего начать инвентаризацию, мы описывали в чек-листе аудита кодовой базы на VB.NET.

Что делать на этой неделе

Официальное описание выпуска — в блоге .NET, подробности уязвимости и временные меры — в бюллетене CVE-2026-111497. Сводку по всем четырём исправлениям опубликовал и GBHackers.

Вопросы и ответы