В VS Code нашли 0-day: один клик мог открыть атакующему доступ к приватным репозиториям GitHub

В экосистеме Visual Studio Code нашли 0-day-уязвимость, которая позволяла украсть GitHub OAuth-токен пользователя после перехода по специально подготовленной ссылке. Токен давал доступ к репозиториям, которые видел сам пользователь, включая приватные проекты.

Уязвимость раскрыл исследователь Аммар Аскар. Он опубликовал технический разбор и PoC-эксплоит. Основная цель атаки — github.dev, браузерная версия VS Code, которую GitHub открывает прямо из репозитория. Пользователь меняет github.com на github.dev в адресной строке или выбирает веб-редактор через интерфейс GitHub, после чего получает рабочую среду VS Code в браузере.

Эта среда умеет читать файлы репозитория, создавать коммиты и отправлять pull request. Для работы GitHub передаёт в github.dev OAuth-токен, который позволяет действовать от имени пользователя. Проблема в том, что токен не ограничен одним открытым репозиторием. Если у разработчика есть доступ к другим приватным проектам, токен может дать доступ и к ним.

Проблема закралась в механике webview — изолированных веб-компонентов VS Code. Webview используют для Markdown-превью, Jupyter Notebook и другого контента, который нужно показать внутри редактора. Идея простая: потенциально опасный JavaScript выполняется в отдельном iframe с другим origin и не должен напрямую управлять главным окном редактора.

В этой схеме нашлась щель. Вредоносный JavaScript внутри webview мог имитировать нажатия клавиш в основном окне VS Code. Дальше открывалась палитра команд, запускалась установка расширения, а расширение уже получало доступ к GitHub OAuth-токену, переданному в github.dev.

Атака выглядела как обычная ссылка. Пользователь открывал подготовленный репозиторий в github.dev, после чего цепочка действий запускалась внутри редактора. Дополнительная фишинговая страница была не нужна. В демонстрации исследователя установленное расширение извлекало токен, обращалось к GitHub API и выводило список приватных репозиториев, доступных жертве.

В цепочке использовалась еще одна особенность VS Code — локальные расширения рабочего пространства. Такие расширения можно разместить в .vscode/extensions внутри проекта. В описанном сценарии это помогало обойти привычную проверку доверия к издателю расширения: код запускался как часть текущей рабочей области.

У GitHub-токена в такой схеме могли быть права на чтение и запись в репозитории. В зависимости от прав пользователя атакующий мог читать закрытые проекты, изучать внутреннюю логику сервисов, искать секреты, менять файлы, готовить pull request или использовать доступ как вход в цепочку supply chain-атаки.

На момент публикации технического разбора уязвимости не был присвоен CVE, а полноценного публичного патча еще не было. Аскар рекомендовал временную меру: очистить cookie и локальные данные сайта для github.dev. После этого при попытке открыть web-редактор пользователь снова увидел бы экран авторизации GitHub Repositories и мог остановить подозрительный сценарий.

Microsoft позже сообщила, что проблема была смягчена на стороне сервисов 3 июня 2026 года. Компания заявила, что дополнительных действий от клиентов не требуется. Представитель Microsoft также уточнил для The Hacker News, что описанный сервисный сценарий не затрагивает настольный VS Code.

В техническом разборе Аскар пишет иначе: похожая проблема возможна и в настольной версии, но эксплуатация сложнее. Для атаки на desktop-сценарий жертву нужно убедить клонировать вредоносный репозиторий и открыть notebook или другой webview-контент с payload. Это уже более длинная цепочка.

История стала заметной из-за способа раскрытия. Исследователь уведомил контакт в GitHub примерно за час до публикации подробностей и PoC, отказавшись от стандартного окна координированного раскрытия. Причиной он назвал предыдущий негативный опыт с Microsoft Security Response Center: ранее найденный им баг, как утверждает исследователь, был исправлен без публичного признания вклада и без оценки как значимой проблемы безопасности.