La vulnerabilità di GitHub.dev consente agli attaccanti di rubare i token OAuth con un clic.

      Ogni sviluppatore che ha mai premuto il tasto punto su un repository GitHub, avviando il comodo editor VS Code basato su browser noto come GitHub.dev, ha accettato inconsapevolmente un accordo. In cambio di un ambiente di codifica leggero, GitHub passa silenziosamente un token OAuth alla sessione, uno che concede accesso in lettura e scrittura a ogni repository a cui l'utente può accedere, non solo al repo che ha aperto.

      Il ricercatore di sicurezza Ammar Askar ha ora dimostrato come un singolo link malevolo possa rubare completamente quel token. L'exploit proof-of-concept, pubblicato il 2 giugno 2026, mette insieme diversi comportamenti di VS Code per installare un'estensione malevola all'interno di GitHub.dev, esfiltrando silenziosamente la credenziale OAuth e enumerando ogni repository privato a cui la vittima può accedere.

      Microsoft ha riconosciuto il difetto e afferma di essere al lavoro su una soluzione. La vulnerabilità non influisce su VS Code Desktop, secondo Alexandru Dima, un manager partner di ingegneria software dell'azienda.

      Come funziona l'attacco

      L'exploit inizia con un link GitHub.dev creato ad arte che punta a un repository contenente un file Jupyter Notebook malevolo. Quando la vittima clicca, GitHub.com invia automaticamente un token OAuth alla sessione di GitHub.dev. Quel token non è limitato al repository specifico, porta pieni privilegi su ogni repo a cui l'utente ha accesso, inclusi quelli privati.

      Il 💜 della tecnologia UE Gli ultimi rumori dalla scena tecnologica dell'UE, una storia dal nostro saggio fondatore Boris e alcune opere d'arte AI discutibili. È gratuito, ogni settimana, nella tua casella di posta. Iscriviti ora! All'interno del notebook, un frammento HTML nascosto con un gestore onerror esegue JavaScript controllato dall'attaccante all'interno di un iframe webview sandboxed. VS Code utilizza questi webview per rendere anteprime Markdown, modificare notebook e visualizzare altri contenuti ricchi. Il difetto critico è che un webview può simulare eventi da tastiera, in particolare eventi keydown, nella finestra principale dell'editor tramite l'API postMessage.

      Il payload attende alcuni secondi affinché VS Code mostri una notifica che richiede l'installazione dell'estensione, quindi invia una simulazione della pressione dei tasti Ctrl+Shift+A. Questa scorciatoia corrisponde al comando "Accetta azione principale della notifica", che approva silenziosamente l'installazione di un'estensione controllata dall'attaccante. L'estensione quindi acquisisce il token OAuth di GitHub e chiama l'API di GitHub per elencare ogni repository privato a cui la vittima può accedere.

      Evitare il controllo di fiducia

      Normalmente, l'installazione di un'estensione di VS Code attiva un prompt di fiducia del publisher. Ma l'exploit evita completamente questo utilizzando una funzionalità chiamata estensioni di workspace locale. Qualsiasi estensione posizionata nella cartella .vscode/extensions di un repository può essere installata senza presentare il dialogo di fiducia, poiché VS Code la tratta come parte dello spazio di lavoro piuttosto che come un download di terze parti.

      L'attaccante può anche aggiungere binding di tasti personalizzati tramite il package.json dell'estensione, mappando comandi arbitrari di VS Code a scorciatoie da tastiera. Poiché l'exploit può attivare in modo affidabile quelle scorciatoie dal webview, può concatenare virtualmente qualsiasi sequenza di azioni dell'editor. "Possiamo semplicemente aggiungere un binding di tasti per qualsiasi comando di VS Code vogliamo, come installare un'estensione saltando il controllo del publisher fidato," ha scritto Askar.

      Perché il ricercatore è andato subito pubblico

      Askar non ha seguito il consueto processo di divulgazione coordinata. Ha detto a The Register che un'esperienza precedente con il Centro di Risposta alla Sicurezza di Microsoft lo ha deluso riguardo al processo. Secondo Askar, MSRC ha silenziosamente corretto un bug di VS Code che aveva segnalato senza accreditarlo e lo ha classificato come privo di impatto sulla sicurezza.

      Ha dato a un contatto di sicurezza di GitHub circa un'ora di preavviso prima di pubblicare i dettagli completi dell'exploit e il codice proof-of-concept. La decisione rispecchia un modello più ampio di frustrazione dei ricercatori con la gestione delle vulnerabilità da parte di Microsoft, che è recentemente aumentato quando l'azienda ha minacciato un altro ricercatore di sicurezza, noto come Nightmare Eclipse, con la prosecuzione penale per aver divulgato pubblicamente zero-day di Windows.

      La divulgazione arriva anche settimane dopo un incidente separato in cui gli hacker hanno violato GitHub stesso tramite un'estensione VS Code avvelenata, rubando circa 3.800 repository interni. Quell'attacco, attribuito a un gruppo monitorato come TeamPCP, ha dimostrato che le estensioni malevole non sono un rischio teorico ma un vettore di minaccia attivo nella catena di fornitura degli sviluppatori.

      L'ambito del rischio

      La vulnerabilità è particolarmente pericolosa perché GitHub.dev non implementa token CSRF, il che significa che qualsiasi link su Internet può reindirizzare un utente nel flusso di attacco. Un singolo clic è sufficiente. Nessun prompt aggiuntivo, nessun dialogo di fiducia, nessun avviso visibile.

      Una volta esfiltrato, l'attaccante ha lo stesso accesso al repository della vittima. Ciò include la lettura del codice sorgente proprietario, l'iniezione di backdoor in progetti privati o il passaggio ad altri sistemi raccogliendo segreti memorizzati in file di configurazione. Per gli sviluppatori che lavorano su infrastrutture aziendali o open-source, il raggio d'azione potrebbe essere significativo.

      Ricerche recenti hanno dimostrato che quando le vulnerabilità negli strumenti per sviluppatori vengono corrette silenziosamente, senza avvisi pubblici o assegnazioni CVE, gli utenti su versioni più vecchie rimangono esposti senza saperlo. Se Microsoft assegnerà un CVE a questo difetto e pubblicherà un avviso formale sarà una prova delle lezioni apprese da quegli episodi precedenti.

      Cosa dovrebbero fare ora gli sviluppatori

      Fino a quando Microsoft non rilascerà una correzione, gli sviluppatori dovrebbero esercitare cautela quando cliccano sui link di GitHub.dev, in particolare quelli che puntano a repository sconosciuti. Rivedere la cartella .vscode/extensions di qualsiasi repository prima di aprirlo nell'editor basato su browser è una precauzione sensata, così come auditare i permessi del token OAuth nelle impostazioni del token di accesso personale di GitHub.

      Le organizzazioni che si affidano a GitHub per codice proprietario potrebbero voler considerare di limitare l'accesso a GitHub.dev fino a quando la vulnerabilità non sarà risolta. Il Security Lab di GitHub, lanciato per aiutare a identificare vulnerabilità nel codice open-source, non ha ancora commentato il difetto.

      La questione più profonda è architettonica. Se un editor basato su browser riceve un token OAuth non limitato per impostazione predefinita, e se le estensioni all'interno di uno spazio di lavoro possono eludere i controlli di fiducia, la superficie di attacco è incorporata nel design. Correggere la specifica catena di exploit è importante, ma il crescente investimento nella sicurezza degli strumenti per sviluppatori, come il recente finanziamento di 18 milioni di dollari raccolto dalla società di sicurezza API Escape, suggerisce che l'industria riconosce che il problema è più profondo di qualsiasi singolo bug.