Un’estensione malevola per VS Code è bastata per aprire una breccia dentro GitHub e accedere a migliaia di repository interni.
Il caso è delicato perché non riguarda un attacco generico contro un servizio qualsiasi, ma uno degli strumenti centrali per chi sviluppa software. Secondo quanto confermato da GitHub, un dispositivo di un dipendente è stato compromesso dopo l’installazione di una versione avvelenata di un’estensione per Visual Studio Code, permettendo agli attaccanti di arrivare a codice e risorse interne.
Il numero circolato è pesante: circa 3.800 repository interni, una cifra che GitHub considera coerente con la propria indagine ancora in corso. L’azienda ha rimosso l’estensione malevola dal marketplace, isolato il dispositivo coinvolto e avviato le procedure di risposta all’incidente. Al momento il punto da tenere fermo è questo: si parla di repository interni di GitHub, non di un accesso generalizzato ai progetti privati degli utenti ospitati sulla piattaforma.
Il problema nasce dagli strumenti degli sviluppatori
La parte più interessante, e anche più preoccupante, riguarda il modo in cui l’attacco è arrivato a destinazione. VS Code è uno degli editor più usati al mondo e le sue estensioni sono una parte normale del lavoro quotidiano: servono per linguaggi, framework, test, completamento del codice, interfacce con servizi esterni e automazioni. Proprio questa fiducia le rende un bersaglio molto appetibile.
Quando uno sviluppatore installa un’estensione, spesso le concede accesso a cartelle di lavoro, terminale, repository locali, token, configurazioni e file sensibili. Se quell’estensione è compromessa, il danno può andare molto oltre il singolo computer. È il cuore della supply chain software: non si colpisce direttamente il prodotto finale, ma uno degli strumenti usati per costruirlo.
Perché non riguarda solo GitHub
Il caso GitHub fa rumore per il nome coinvolto, ma il rischio è più ampio. VS Code viene usato da freelance, agenzie, startup, aziende, team IT e sviluppatori indipendenti. Un’estensione apparentemente legittima può diventare una porta d’ingresso verso codice sorgente, credenziali, chiavi API, segreti di progetto e dati interni. E spesso il problema non viene notato subito, perché l’estensione continua a sembrare normale.
Per questo non basta pensare “è successo a GitHub, quindi riguarda solo GitHub”. Il messaggio per chi sviluppa è molto più concreto: ogni componente installato nell’ambiente di lavoro va trattato come parte della superficie d’attacco. Anche un plugin scaricato da un marketplace ufficiale può diventare rischioso se viene compromesso, aggiornato con codice malevolo o imitato da una copia credibile.
La fiducia nei plugin va rivista
GitHub ha reagito rimuovendo la versione malevola, isolando il dispositivo e avviando la risposta interna. Alcune ricostruzioni collegano l’episodio al gruppo TeamPCP e alla vendita dei dati rubati, ma queste parti vanno lette come rivendicazioni e analisi esterne, non come conferme definitive su ogni dettaglio. Il dato centrale resta la fragilità degli strumenti di sviluppo quando entrano nel flusso quotidiano senza controlli adeguati.
Per sviluppatori e aziende, la lezione è scomoda ma chiara. Bisogna ridurre le estensioni inutili, verificare autore e aggiornamenti, limitare i permessi, proteggere i token e ruotare rapidamente le credenziali se c’è anche solo il sospetto di compromissione. Un editor moderno non è più solo un programma per scrivere codice: è un punto di accesso a progetti, infrastrutture e segreti. E quando viene colpito quello, la sicurezza del software inizia a scricchiolare molto prima della pubblicazione.
