GitHub e Visual Studio Code finiscono al centro di una scoperta che mette in discussione uno dei presupposti fondamentali della sicurezza degli ambienti di sviluppo web-based. Il ricercatore Ammar Askar ha pubblicato un’analisi dettagliata di una vulnerabilità presente in github.dev, la versione browser-based di VSCode integrata direttamente nella piattaforma GitHub, che consente a un attaccante di rubare il token OAuth dell’utente con un solo click. L’attacco non richiede download manuali, installazioni volontarie o concessioni esplicite di permessi. È sufficiente aprire un link appositamente preparato che punta a un notebook Jupyter maligno ospitato su GitHub. Da quel momento una catena di eventi sfrutta il modello di comunicazione dei webview VSCode, installa un’estensione malevola e trasmette all’attaccante il token GitHub associato all’utente. Il problema è particolarmente grave perché il token utilizzato da github.dev non è limitato a un singolo repository ma concede accesso in lettura e scrittura a tutti i repository accessibili dall’account, inclusi quelli privati. La vulnerabilità dimostra come la crescente convergenza tra editor, browser e piattaforme cloud possa introdurre nuove superfici di attacco difficili da individuare con i modelli di sicurezza tradizionali.
Cosa leggere
Ammar Askar pubblica la vulnerabilità che colpisce github.dev
Il 2 giugno 2026 il ricercatore Ammar Askar rende pubblica la vulnerabilità attraverso una dettagliata analisi tecnica. Secondo la ricostruzione, il problema deriva dal modo in cui github.dev integra VSCode nel browser e gestisce la comunicazione tra i contenuti caricati nei webview e l’istanza principale dell’editor. L’exploit dimostra che un semplice click su un link verso un repository malevolo può essere sufficiente per compromettere l’account GitHub della vittima. Askar spiega che il token OAuth utilizzato da github.dev viene trasferito dal dominio GitHub all’editor web per consentire operazioni sui repository.
Questo token possiede privilegi estesi e permette di eseguire modifiche, consultare codice privato e interagire con risorse normalmente accessibili dall’utente autenticato. La scoperta nasce dall’analisi del comportamento dei webview e dalla ricerca di metodi per aggirare le restrizioni imposte dalla separazione delle origini. Secondo il ricercatore, la vulnerabilità non richiede capacità avanzate da parte dell’attaccante e può essere sfruttata in campagne di massa contro sviluppatori, maintainer open source e dipendenti aziendali che utilizzano github.dev per revisioni rapide del codice.
Il funzionamento del token OAuth in github.dev
Quando un utente apre un repository tramite github.dev, GitHub trasferisce all’ambiente web di VSCode un token OAuth che permette all’editor di operare per conto dell’utente. Questa scelta migliora l’esperienza d’uso perché elimina autenticazioni ripetute e rende immediato l’accesso ai repository. Tuttavia il token possiede privilegi molto più ampi di quanto molti sviluppatori immaginino. Non è confinato al repository attualmente aperto ma estende la propria validità a tutte le risorse GitHub accessibili dall’account. In termini pratici, un aggressore che riesce a sottrarre questo token può leggere repository privati, modificare codice, creare commit, cancellare file o distribuire modifiche malevole. Il problema non riguarda soltanto il singolo progetto visitato dalla vittima ma l’intero patrimonio di codice associato all’account GitHub compromesso. Questa architettura privilegia la comodità operativa ma aumenta drasticamente l’impatto di eventuali vulnerabilità che riescano a raggiungere il token durante la sessione di lavoro.
Il ruolo dei webview nel modello di sicurezza di VSCode
La vulnerabilità nasce dal comportamento dei webview di VSCode, componenti utilizzati per visualizzare contenuti complessi come notebook, estensioni e pannelli interattivi. I webview operano in un’origine separata rispetto all’istanza principale dell’editor e, teoricamente, non dovrebbero avere accesso diretto agli elementi più sensibili dell’applicazione. La comunicazione avviene tramite postMessage, meccanismo progettato per mantenere isolate le varie componenti. Tuttavia Askar individua un dettaglio cruciale: il webview inoltra automaticamente gli eventi keydown all’istanza principale di VSCode. Questo comportamento permette a codice JavaScript eseguito nel webview di simulare combinazioni di tasti e attivare comandi privilegiati dell’editor. Sebbene il modello impedisca la manipolazione diretta del DOM principale, la possibilità di generare eventi di tastiera sintetici crea un canale indiretto attraverso cui influenzare operazioni normalmente riservate all’utente.
Notebook Jupyter maligni come vettore di compromissione
Per sfruttare la vulnerabilità, l’attaccante utilizza un notebook Jupyter costruito appositamente. All’interno di una cella markdown viene inserito un elemento HTML apparentemente innocuo che contiene un tag img con un attributo onerror. Quando il browser tenta di caricare l’immagine inesistente, il codice JavaScript associato viene eseguito automaticamente. Questo script non tenta di rubare direttamente il token ma prepara l’ambiente per la fase successiva dell’attacco. Il payload attende che determinate notifiche di VSCode siano disponibili e poi utilizza eventi di tastiera simulati per interagire con l’interfaccia dell’editor. L’utente non vede finestre di installazione sospette né richieste esplicite di autorizzazione. Tutto avviene in background sfruttando meccanismi legittimi dell’applicazione. Il notebook diventa quindi il veicolo ideale perché può essere distribuito come contenuto apparentemente innocuo all’interno di un repository pubblico e condiviso attraverso social network, issue tracker o discussioni tecniche.
Simulazione di input e installazione dell’estensione malevola
Il passaggio più delicato dell’exploit riguarda l’installazione di un’estensione workspace controllata dall’attaccante. Attraverso la simulazione di combinazioni come Ctrl+Shift+A e altri keybinding personalizzati, il payload convince VSCode ad accettare automaticamente una raccomandazione di installazione. L’estensione viene caricata nel contesto trusted del workspace e ottiene privilegi sufficienti per accedere alle API interne dell’ambiente github.dev. Da quel momento l’attaccante può eseguire codice con capacità molto superiori rispetto a quelle disponibili nel notebook iniziale. La tecnica sfrutta la fiducia che VSCode ripone nelle estensioni locali e dimostra come il confine tra contenuto visualizzato e codice eseguibile possa essere aggirato attraverso una sequenza di azioni apparentemente legittime. Il risultato è un processo quasi invisibile che trasforma un semplice documento in un meccanismo di compromissione completa dell’ambiente di sviluppo web.
Furto del token GitHub e accesso ai repository privati
Una volta installata, l’estensione malevola recupera il token OAuth utilizzato dalla sessione github.dev e lo trasmette all’infrastruttura dell’attaccante. Il token consente immediatamente di interrogare le API GitHub, elencare repository, accedere a codice privato e verificare i privilegi disponibili. Secondo il proof-of-concept pubblicato dal ricercatore, il malware mostra persino l’elenco completo dei repository accessibili come dimostrazione della compromissione avvenuta. L’impatto può essere enorme per sviluppatori che lavorano su progetti aziendali, repository privati o infrastrutture software critiche. Un attaccante potrebbe clonare il codice sorgente, inserire backdoor, rubare segreti applicativi o preparare attacchi alla supply chain software. Poiché il token resta valido fino alla scadenza naturale o alla revoca manuale, il rischio non termina con la chiusura della finestra del browser ma può protrarsi per un periodo significativo.
La vulnerabilità interessa anche la versione desktop di VSCode
Sebbene il focus principale riguardi github.dev, Askar sottolinea che la stessa logica di forwarding degli eventi è presente anche nella versione desktop di VSCode. In questo caso l’attacco risulta più difficile da attivare perché richiede condizioni aggiuntive e una catena di exploit più complessa. Tuttavia il principio resta identico: un contenuto controllato da un aggressore può utilizzare i webview per simulare input utente e attivare funzionalità privilegiate. La scoperta amplia quindi il dibattito oltre github.dev e coinvolge direttamente il modello architetturale di VSCode. La questione non riguarda un singolo bug isolato ma un comportamento di progettazione che potrebbe favorire ulteriori vulnerabilità in futuro. Per questo motivo molti ricercatori stanno analizzando con maggiore attenzione il rapporto tra webview, estensioni e comandi interni dell’editor.
Il proof-of-concept pubblico e le tensioni con Microsoft
Un elemento che ha attirato l’attenzione della comunità riguarda la decisione di Ammar Askar di pubblicare immediatamente il proof-of-concept completo. Il ricercatore spiega di aver scelto questa strada dopo precedenti esperienze negative con il Microsoft Security Response Center, che in casi passati avrebbe corretto vulnerabilità simili senza attribuire adeguatamente il merito della scoperta. Prima della pubblicazione Askar ha comunque notificato il problema a GitHub Security e aperto una segnalazione ufficiale sul progetto VSCode. La pubblicazione include codice sorgente, repository dimostrativi e tutti i dettagli necessari a riprodurre l’attacco. Questa scelta accelera la consapevolezza del rischio ma aumenta anche la pressione su Microsoft e GitHub affinché rilascino rapidamente una correzione. Nel frattempo, chiunque disponga delle competenze necessarie può studiare l’exploit e comprenderne il funzionamento nel dettaglio.
Le contromisure immediate per gli utenti GitHub
In attesa di una patch ufficiale, il ricercatore suggerisce una serie di mitigazioni pratiche. La più importante consiste nel cancellare i dati locali associati a github.dev, eliminando cookie, storage e informazioni persistenti che permettono il mantenimento della sessione. Gli utenti dovrebbero inoltre evitare di aprire notebook Jupyter, repository o file provenienti da fonti non fidate direttamente tramite github.dev. Una particolare attenzione va riservata ai link condivisi sui social network, nei commenti delle issue o nelle discussioni tecniche pubbliche. Anche la revisione delle estensioni installate e la revoca preventiva dei token sospetti rappresentano misure prudenti. Gli sviluppatori che utilizzano frequentemente github.dev dovrebbero considerare il servizio come un ambiente potenzialmente esposto fino alla distribuzione di una correzione definitiva.
Un problema che mette in discussione il trust model di VSCode
La vulnerabilità evidenzia una debolezza più ampia nel modello di fiducia adottato da VSCode. Il forwarding automatico degli eventi di tastiera dai webview verso l’editor principale crea infatti una superficie di attacco che può essere sfruttata da contenuti apparentemente innocui. Tecnologie come Content Security Policy e DOMPurify limitano alcune forme di esecuzione arbitraria, ma non impediscono l’abuso dei meccanismi di input sintetico. Il caso dimostra che la separazione delle origini non è sufficiente se esistono canali indiretti capaci di influenzare componenti privilegiate dell’applicazione. Microsoft dovrà probabilmente rivalutare il comportamento dei webview, limitare l’inoltro degli eventi e rafforzare il controllo sulle estensioni workspace locali. Per gli sviluppatori la lezione è chiara: anche strumenti progettati per aumentare la produttività possono diventare vettori di compromissione quando la fiducia tra componenti diverse non viene delimitata con precisione.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
