VS Code zero-day: furto token GitHub con un solo click

Una vulnerabilità zero-day nella webview di VS Code consente il furto di token OAuth GitHub e RCE su desktop con un singolo click, senza interazione aggiuntiva.

Contenuto

VS Code zero-day: furto token GitHub con un solo click
VS Code zero-day: furto token GitHub con un solo click

Un ricercatore di sicurezza ha pubblicato il 2 giugno 2026 una vulnerabilità zero-day in Visual Studio Code. Ammar Askar ha divulgato che un singolo click su un link malevolo innesca il furto di token OAuth GitHub con accesso a tutti i repository privati di un utente, e ottiene esecuzione remota di codice sulla versione desktop, con zero interazione successiva. Askar ha notificato un contatto sicurezza GitHub un'ora prima della pubblicazione, senza coordinazione con Microsoft MSRC.

Punti chiave
  • Un click su un link github.dev innesca l'intera catena di exploit: il payload JavaScript completo esegue in meno di un minuto senza ulteriore interazione dell'utente.
  • Il token OAuth GitHub ottenuto è unscoped: la fonte riporta che concede accesso in lettura/scrittura a ogni repository privato dell'utente, non solo a quello aperto.
  • Il meccanismo sfrutta il forwarding dei keyboard events via postMessage nella webview di VS Code, che collega contenuto non attendibile con API pericolose.
  • Sulla versione desktop l'exploit ottiene RCE completo attraverso le API Node.js, incluso child_process, accessibili alle estensioni.

Come funziona il bypass della sandbox webview

VS Code isola il contenuto non attendibile delle webview in iframe con origine vscode-webview://, separata dall'editor principale su vscode-file://. La comunicazione tra i due contesti avviene via Window.postMessage().

Per garantire l'esperienza utente, VS Code registra un handler did-keydown che inoltra ogni evento tastiera dalla webview all'editor principale. Questo permette shortcut come Ctrl+Shift+P anche all'interno delle webview.

Secondo la descrizione tecnica pubblicata da Askar, questo canale postMessage per il forwarding dei keyboard events "compromette la security boundary che dovrebbe separare le Dangerous APIs dall'Untrusted User Content, collegandole involontariamente". JavaScript non attendibile in una webview può creare fake keydown events, simulando input utente.

Il PoC pubblicato sfrutta file Jupyter Notebook (.ipynb) con tag HTML onerror o file .vscode/extensions.json per eseguire JavaScript arbitrario nella webview. Il payload attende la comparsa di una notifica di raccomandazione estensione, quindi invia un synthetic Ctrl+Shift+A che accetta silenziosamente l'azione primaria della notifica: l'installazione dell'estensione malevola.

La catena da un click all'RCE: cinque stadi in meno di un minuto

L'intera catena di exploit si compone in cinque stadi concatenati. Il primo è il click iniziale su un link che reindirizza a github.dev con un workspace malevolo. Il secondo stadio vede la webview eseguire JavaScript che simula il keydown Ctrl+Shift+A.

Nel terzo stadio, la notifica di raccomandazione estensione viene accettata silenziosamente. Nel quarto, l'estensione malevola viene piazzata in .vscode/extensions/ con skipPublisherTrust=true, sfruttando il fatto che i workspace github.dev sono sempre trusted.

Nel quinto stadio, l'estensione installata accede al token OAuth GitHub pre-caricato ed esfiltra l'elenco dei repository privati. Sulla versione desktop di VS Code, l'exploit ottiene RCE completo. Le estensioni dispongono di accesso illimitato alle API Node.js, incluse child_process.

"The full JavaScript payload executes in well under a minute and requires zero interaction beyond the initial link click" — Ammar Askar (via CyberSecurityNews)

Perché github.dev è il bersaglio perfetto

La vulnerabilità colpisce in modo particolarmente efficace github.dev, l'editor VS Code integrato in GitHub, per una caratteristica architetturale documentata dalla fonte: quando un utente naviga da github.com a github.dev, GitHub invia automaticamente in POST un token OAuth unscoped alla sessione github.dev.

La fonte specifica che questo token "grants full access to every repository the user has access to not just the one they opened". La mancanza di token CSRF su github.dev amplifica il rischio: qualsiasi link su internet può reindirizzare un utente verso l'attacco.

L'assenza di un indicatore visivo di pericolo durante l'esecuzione del payload rende l'utente ignaro del compromesso fino all'esfiltrazione dei dati. Link github.dev condivisi in issue, pull request, messaggi Slack o email possono funzionare come vettori con effetto deterministico.

Cosa fare adesso

La fonte non documenta patch rilasciate da Microsoft o GitHub al momento della disclosure. Gli utenti di github.dev non dispongono di mitigazioni documentate per bloccare autonomamente il vettore postMessage keyboard forwarding.

Le azioni specifiche al caso, basate sui fatti verificati, sono:

  • Verificare l'origine di ogni link github.dev prima del click, dato che la fonte conferma zero interazione successiva e assenza di CSRF tokens.
  • Controllare la presenza di estensioni non richieste in workspace github.dev, in particolare in .vscode/extensions/, dato che il bypass skipPublisherTrust sfrutta il trust automatico dei workspace.
  • Limitare la condivisione di link github.dev in canali non attendibili, dato che qualsiasi link su internet può reindirizzare verso l'attacco.
  • Monitorare l'accesso OAuth alle applicazioni GitHub collegate, dato che il token ottenuto è unscoped e la fonte non documenta revoca automatica.

Per gli ambienti enterprise, la fonte non specifica policy di restrizione disponibili. La CSP (script-src 'none') sulle pagine Markdown preview delle estensioni e l'uso di DOMPurify, menzionati da Askar, limitano percorsi RCE alternativi ma non mitigano il vettore principale documentato.

La disclosure e il contesto istituzionale

Askar ha notificato un contatto sicurezza di GitHub un'ora prima della pubblicazione, bypassando Microsoft MSRC. La fonte riporta che il ricercatore ha motivato questa scelta con "prior negative experiences". Il timing compresso e l'assenza di coordinazione con il vendor rappresentano una rottura del modello standard di responsible disclosure.

La tensione è leggibile in termini istituzionali: quando il canale ufficiale perde la fiducia dei ricercatori, il full disclosure diventa strumento di pressione. Se questo modello si normalizza per Microsoft, la capacità di gestire proattivamente vulnerabilità critiche ne risentirà.

Il caso si inserisce in un pattern più ampio di rischio per la supply chain VS Code. Le fonti contestuali documentano precedenti di estensioni compromesse, ma questi incidenti distinti — Nx Console (maggio 2026), estensioni AI-branded con 1,5 milioni di installazioni — non condividono il meccanismo tecnico del zero-day webview postMessage.

"Since github.dev does not implement CSRF tokens, any link on the internet can redirect a user into this attack" — Ammar Askar (via CyberSecurityNews)

Il rischio numerico in sintesi

La vulnerabilità si condensa in tre metriche chiave verificate dalla fonte: 1 click per innescare l'attacco, meno di un minuto per l'esecuzione completa del payload, zero interazione oltre al click iniziale. Il token OAuth ottenuto è unscoped, con accesso a tutti i repository privati dell'utente.

La fonte non quantifica il numero di utenti potenzialmente esposti né conferma exploitazione attiva prima della disclosure. Nessun CVE è stato assegnato al momento della pubblicazione. Lo stato della patch non è documentato nelle fonti disponibili.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti

Link utili

Apri l'articolo su DeafNews