В Microsoft Visual Studio нашлась ошибка проверки сертификатов. Из-за неё среда разработки принимает поддельный сетевой узел за доверенный. В результате атакующий может выдать себя за легитимный источник данных. Затронуты линейки Visual Studio 2017, 2019, 2022 и 2026.
Среда разработки доверяет поддельному сертификату
Пока запись CVE-2026-118147 оставалась зарезервированной, детали уязвимости не раскрывали. Резерв оформили 27 октября 2026 года, а публичное раскрытие состоялось 30 октября, когда Microsoft выпустила бюллетень безопасности. На следующий день запись получила статус PUBLISHED. Оценка по CVSS 3.1 составляет 7.4, это высокий уровень по шкале от 0 до 10. Сведений об эксплуатации в реальных атаках Microsoft не приводит.
При этом слабость относится к классу CWE-295, то есть к некорректной проверке сертификатов. Сертификат подтверждает подлинность сетевого узла, а цепочка доверия связывает его с удостоверяющим центром. Когда проверка ошибается, подпись перестаёт быть гарантией. Из-за этого ответ чужого узла выглядит для Visual Studio как ответ доверенного сервера. В результате среда работает с подменёнными данными как с обычными.
Однако запись говорит не о запуске чужого кода, а о подмене. Это меняет приоритет, хотя пренебрегать патчем не стоит. При подмене страдает доверие к данным, а не сама система. Иначе говоря, атакующий влияет на то, что среда считает подлинным. Для разработчика это оборачивается работой с чужими данными под видом своих.
Условия атаки и последствия
Атака идёт по сети, однако сложность у неё высокая. Значит, атакующему нужно повлиять на сетевой обмен между средой разработки и сервером. Привилегии на целевой машине ему не нужны, участие пользователя тоже не требуется. Высокая сложность означает, что массово использовать уязвимость трудно. Тем не менее для отдельной организации успешная подмена возможна.
Кроме того, среда разработки стоит на машине с доступом к репозиториям, сборкам и учётным данным. Если она доверяет поддельному узлу, подмена затрагивает и эти ресурсы. Из-за этого ошибка проверки сертификата превращается в риск для всей цепочки сборки. Доступность от подмены не страдает, зато конфиденциальность и целостность страдают. Патч здесь касается не только удобства разработчика, но и защиты инфраструктуры.
Исправленные сборки
Чтобы закрыть уязвимость, Microsoft выпустила исправления в бюллетене безопасности CVE-2026-118147 от 30 октября 2026 года. Уязвимы Visual Studio 2017 версии 15.9 ниже 15.9.84 и Visual Studio 2019 версии 16.11 ниже 16.11.62. Также в список попали Visual Studio 2022 версии 17.14 ниже 17.14.44. Замыкает перечень Visual Studio 2026 версии 18.11 ниже 18.11.3. Microsoft относит к уязвимым только сборки ниже этих номеров.
В самой записи CVE номер исправленной версии отсутствует, поэтому сверяйтесь с бюллетенем вендора. Обходных мер Microsoft не привела, так что закрыть уязвимость можно только обновлением. После установки среда снова проверяет цепочку доверия так, как задумано. Кроме того, обновлять стоит все линейки, которые используются в организации, а не только самую свежую. Разные команды нередко работают в разных версиях среды.
Порядок действий для администратора
Также проверьте, какие сборки Visual Studio стоят на рабочих машинах и серверах сборки. Номер сборки виден в справке среды, так что по нему легко сравнить установку с границей из бюллетеня. Когда установка старше границы, ставьте пакет исправлений. После этого сверьте номер ещё раз, чтобы убедиться в результате. Обновление лучше не откладывать до следующего планового цикла.
При этом приоритет стоит отдать серверам сборки и машинам с широким доступом к репозиториям. На них подмена затрагивает больше данных, чем на рядовой рабочей станции. Хотя сложность атаки высокая, откладывать патч на месяцы не стоит. Если в организации есть отдельный стенд для проверки обновлений, начните с него. Так обновление пройдёт без сюрпризов для команд, которые работают в старых версиях среды.
Если машин много, обновление стоит разбить на этапы. Сначала обновляют серверы сборки, потом рабочие станции разработчиков. Дополнительно полезно записать номера сборок до и после установки. Эти записи пригодятся, если позже понадобится подтвердить версию среды. Тогда обновление охватит весь парк машин, а не отдельные установки.