Исследователь по безопасности опубликовал готовый эксплойт для уязвимости нулевого дня в Visual Studio Code, которая позволяет похитить токен авторизации GitHub: жертве достаточно перейти по ссылке. Уязвимостью нулевого дня называют брешь, ставшую известной (публично раскрытой и/или уже используемой в атаках) до того, как у разработчика появилось исправление: у защищающейся стороны остаётся «ноль дней» на реакцию. По этому критерию Microsoft и относит брешь к нулевым дням, и нынешний случай ему отвечает – эксплойт опубликован, а патча нет.
Как описал в своём блоге исследователь Аммар Аскар (Ammar Askar), брешь даёт возможность установить вредоносное расширение, которое перехватывает OAuth-токен GitHub в момент его передачи на github.dev – браузерную версию Visual Studio Code для работы с репозиториями. Атака эксплуатирует механизм обмена сообщениями между изолированными webview редактора.
github.dev открывается при замене github.com на github.dev в адресе репозитория либо через отдельный пункт меню в веб-интерфейсе. Это облегчённая копия VS Code, работающая целиком в браузере: она позволяет просматривать файлы (в том числе в приватных репозиториях), создавать коммиты и отправлять запросы на слияние. Чтобы выполнять эти действия от имени пользователя, github.com передаёт на github.dev OAuth-токен. Ключевая проблема в том, что токен не ограничен областью одного репозитория – он даёт доступ ко всем репозиториям, к которым у жертвы есть доступ.
Репозиторий, открытый в github.dev (источник: Ammar Askar)
Опубликованный 2 июня 2026 года рабочий пример атаки (proof-of-concept) запускает вредоносный JavaScript внутри webview, имитирует нажатия клавиш в основном окне редактора и ставит расширение, которое извлекает переданный на github.dev OAuth-токен, после чего обращается к GitHub API и перечисляет доступные приватные репозитории.
VS Code построен на Electron, поэтому потенциально небезопасное содержимое он выполняет в webview – это элементы iframe с отдельным источником (origin) vscode-webview://, отличным от основного окна vscode-file://. Кросс-доменная изоляция не даёт JavaScript внутри webview напрямую вызывать API Node.js или редактора. В таких песочницах отрисовываются предпросмотр Markdown и вывод ячеек Jupyter Notebook.
Чтобы редактор и webview могли взаимодействовать (например, синхронизировать предпросмотр Markdown с текущей строкой кода), VS Code использует Window.postMessage(). Для удобства реализация webview регистрирует обработчик did-keydown, который пересылает каждое нажатие клавиши из webview в основное окно через postMessage – так горячие клавиши вроде Ctrl+Shift+P продолжают работать, когда фокус находится внутри webview. Именно здесь и кроется брешь: недоверенный код в webview может сформировать поддельные события нажатий и выдать их за действия пользователя. Граница, которая должна отделять опасные API от недоверенного содержимого, оказывается стёртой.
Граница безопасности webview и канал postMessage (источник: Ammar Askar)
Полная цепочка атаки опирается на пять связанных особенностей VS Code. Сначала вредоносный файл .ipynb (Jupyter Notebook) выполняет произвольный JavaScript через тег изображения с обработчиком onerror. Затем нагрузка ждёт уведомление о рекомендуемых расширениях (их задаёт файл .vscode/extensions.json) и отправляет синтетическое нажатие Ctrl+Shift+A – команду Notifications: Accept Notification Primary Action, которая нажимает основную кнопку последнего уведомления и запускает установку расширения.
Уведомление об установке рекомендуемого расширения (источник: Ammar Askar)
Вместо установки из Marketplace, где сработал бы диалог подтверждения издателя, злоумышленник размещает расширение прямо в каталоге .vscode/extensions. Такой способ обходит проверку доверенного издателя и опирается только на доверие к рабочей области, а области github.dev доверенными считаются всегда.
Диалог подтверждения издателя, который обходит атака (источник: Ammar Askar)
Из-за политики безопасности контента (CSP) локальное расширение не может загрузить свои скрипты ниоткуда, кроме vscode-cdn.net; чтобы обойти ограничение, в package.json добавляется собственная привязка клавиш (например, Ctrl+F1), которая вызывает команду workbench.extensions.installExtension с параметром skipPublisherTrust. После установки расширение получает доступ к загруженному OAuth-токену GitHub, обращается к https://api.github.com/user/repos, перечисляет приватные репозитории и выгружает токен вместе со списком наружу.
Рабочий пример выводит токен и список приватных репозиториев (источник: Ammar Askar)
Вся нагрузка отрабатывает менее чем за минуту и не требует от пользователя никаких действий, кроме первого клика по ссылке.
Уязвимость затрагивает не только браузерный github.dev, но и настольную версию VS Code, хотя там атака сложнее: жертву нужно убедить клонировать и открыть репозиторий злоумышленника. В настольной версии успешная атака приводит к полному удалённому выполнению кода (RCE) – расширения VS Code имеют неограниченный доступ к API Node.js, включая child_process.
Поскольку украденный токен не ограничен одним репозиторием, атакующий может незаметно читать, изменять и отправлять изменения во все приватные репозитории жертвы. На github.dev нет защиты от подделки межсайтовых запросов (CSRF-токенов), поэтому перенаправить на атаку способна любая ссылка в интернете.
В качестве защиты Аскар рекомендует очистить данные сайта github.dev в браузере (в Chrome – значок в адресной строке, далее «Файлы cookie и данные сайтов», управление данными на устройстве, удалить все домены github.dev). Это возвращает начальный диалог подтверждения и даёт шанс уйти со страницы. Также не стоит открывать незнакомые ссылки github.dev до выхода исправления, нужно проверить установленные на github.dev расширения и удалить незнакомые. Пользователи, которые ни разу не заходили на github.dev и очистили локальное хранилище, защищены начальным диалогом согласия.
Исследователь отметил, что эшелонированная защита VS Code ограничила последствия. Строгая политика безопасности контента (script-src 'none') на страницах предпросмотра Markdown для расширений блокирует выполнение произвольного JavaScript и закрывает ещё более простой путь к RCE одним кликом, а очистка разметки через DOMPurify перекрывает межсайтовый скриптинг.
Аскар выложил уязвимость в режиме полного раскрытия, без предварительного согласования с Microsoft. Своё решение он объяснил прошлым опытом обращения в Центр реагирования на угрозы безопасности Microsoft (MSRC): по его словам, ранее найденную им брешь в VS Code тихо исправили без указания авторства и пометили как не имеющую отношения к безопасности, а сообщения об ошибках github.dev помечались как выходящие за рамки рассмотрения. О публикации он за час уведомил знакомого из службы безопасности GitHub. На момент раскрытия исправления нет.
Это не первый случай, когда исследователи переходят к полному раскрытию из-за недовольства реакцией Microsoft. Ранее поток уязвимостей нулевого дня в продуктах Microsoft публиковал анонимный исследователь под псевдонимом «Nightmare Eclipse» – среди них уязвимость нулевого дня YellowKey (CVE-2026-45585); на эти раскрытия Microsoft отвечала отдельно. А в мае 2026 года сама GitHub столкнулась с компрометацией около 3800 внутренних репозиториев через вредоносную версию расширения Nx Console для VS Code – ещё одно напоминание, что инструменты разработчика стали отдельным вектором атак.