Уязвимость VS Code позволяла красть токены GitHub в один клик

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

Именно такую уязвимость показал исследователь Ammar Askar. Microsoft ещё не выпустила патч, а значит, речь идёт о типичном zero-day — уязвимости, о которой уже известно публично, но закрыть её пока нечем.

1. История инцидента

По описанию исследователя, проблема затрагивает связку VS Code и github.dev — браузерную версию редактора, которую разработчики используют для работы с репозиториями GitHub. Атакующий мог заманить пользователя на ссылку, а затем через уязвимость запустить вредоносный код внутри sandboxed webview — изолированного окна, которое VS Code использует для веб-контента.

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

Смысл атаки прост: токен не привязан к одному проекту. Если злоумышленник его получил, он получает не один репозиторий, а всё, что открыто пользователю по правам доступа.

2. Что пошло не так в защите

Главная проблема — доверие между компонентами. VS Code старается изолировать webview, но уязвимость показала, что сообщение между песочницей и основным редактором можно использовать против самого приложения.

Вторая слабая точка — передача токена в браузерную среду. Как только секрет оказывается в зоне, где его можно перехватить через цепочку скриптов и расширений, защита уже держится не на одном барьере, а на нескольких допущениях сразу.

Такие истории хорошо объясняют, почему токены и сессии нельзя считать «мелочью». Для атакующего это не просто строка в памяти, а ключ от рабочих данных, переписок и кода.

Отдельный слой риска — социальная инженерия. Пользователь видит знакомую среду, знакомую ссылку и привычный интерфейс. В этой точке атака уже похожа не на взлом с громкими сигналами, а на грамотную подмену действия: человек сам нажимает туда, куда его подталкивают.

3. Уроки для читателя

Первый вывод простой: браузерная версия инструмента разработки — не игрушка и не «облегчённый режим». Если вы работаете с приватными проектами, любая лишняя ссылка, любое незнакомое расширение и любое странное окно авторизации требуют паузы.

Второй вывод касается гигиены токенов. Срок жизни секретов должен быть коротким, права — минимальными, а лишние сессии и устройства лучше регулярно отключать. Чем меньше токен умеет, тем меньше ущерб от его кражи.

Третий момент — обновления и контроль окружения. Слабое место может сидеть не в коде проекта, а в редакторе, расширении или браузере. Поэтому безопасная работа с репозиториями — это не только пароли и 2FA, но и проверка того, что установлено в системе.

На фоне этой истории полезно вспомнить и другой слой защиты — фишинг через ссылки и подмену переходов. Мы разбирали это в материале о том, как распознать подмену ссылки: в кибератаках почти всегда первым ломают не систему, а внимание.

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

4. Практические выводы и чек-лист

Вот что стоит сделать прямо сейчас, если вы работаете с GitHub и VS Code:

• Очистить cookies и данные сайта для github.dev в браузере, если вы пользуетесь этой средой.
• Проверить, не остались ли активные сессии и лишние устройства в настройках аккаунта GitHub.
• Пересмотреть права токенов и убрать всё, что не нужно для ежедневной работы.
• Не ставить расширения из сомнительных источников и удалить лишние.
• Обновить VS Code и браузер до последних версий.
• Включить двухфакторную аутентификацию, если она ещё не включена.
• С осторожностью открывать ссылки на редакторы, репозитории и приглашения к совместной работе.
• Для удалённой работы и поездок заранее проверять, какие данные уходят через устройство и какие сервисы у вас открыты.

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