La ricerca di Bloom Security sull'estensione Resurrection mette in luce un punto cieco nella sicurezza degli sviluppatori.

      TL;DRLa ricerca "Extension Resurrection" di Bloom Security ha scoperto che pacchetti di estensioni legittimi di VS Code e Open VSX possono fare riferimento a estensioni che non esistono nel marketplace. Gli attaccanti potrebbero rivendicare quegli spazi dei nomi e pubblicare estensioni dannose che si installano automaticamente tramite pacchetti fidati. 677 di 4.179 pacchetti di VS Code e 94 di 321 pacchetti di Open VSX erano vulnerabili, con oltre 500.000 download combinati. Sia Microsoft che la Eclipse Foundation hanno successivamente implementato protezioni dopo la divulgazione di Bloom. I team di sicurezza hanno trascorso anni a scrutinare le dipendenze software, i repository di pacchetti e le pipeline di build. L'ultima ricerca di Bloom Security suggerisce che un'altra parte della catena di approvvigionamento software merita maggiore attenzione: le estensioni che gli sviluppatori installano all'interno dei loro IDE. La ricerca "Extension Resurrection" dell'azienda ha esaminato i pacchetti di estensioni nel Visual Studio Code Marketplace e in Open VSX. Bloom ha scoperto che pacchetti legittimi potrebbero contenere riferimenti a estensioni che in realtà non esistevano nel marketplace, creando un'opportunità per gli attaccanti di rivendicare quegli spazi dei nomi non utilizzati e pubblicare estensioni dannose sotto di essi. La ricerca ha identificato 94 di 321 pacchetti di estensioni Open VSX con almeno una "Dipendenza Ombra". Nel Marketplace di VS Code, Bloom ha trovato 677 di 4.179 pacchetti con almeno una di queste dipendenze. Tra i pacchetti vulnerabili, i download hanno superato 500.000. Il vero problema è il modello di fiducia. Ciò che rende la scoperta notevole è che l'attacco non dipende dal convincere uno sviluppatore a installare un'estensione sconosciuta. Lo sviluppatore ha già preso una decisione di fiducia installando un pacchetto di estensioni legittimo. Quella decisione può estendersi a più dipendenze che l'utente potrebbe non esaminare mai singolarmente. La ricerca di Bloom mostra come un'estensione mancante all'interno di quella catena possa diventare un'opportunità se il marketplace continua a riconoscerne l'identità consentendo a qualcun altro di registrare lo spazio dei nomi corrispondente. Il risultato è una disconnessione tra ciò che gli sviluppatori credono di aver approvato e ciò che il loro ambiente di sviluppo può infine installare. L'automazione amplifica il problema. La ricerca di Bloom evidenzia anche il ruolo degli aggiornamenti automatici. I pacchetti di estensioni non fissano le loro estensioni incorporate a versioni specifiche, il che significa che un pacchetto installato in passato può potenzialmente acquisire una nuova versione pubblicata di una dipendenza precedentemente mancante. Ciò cambia la natura del rischio. Un'organizzazione non ha necessariamente bisogno di installare un'estensione dannosa oggi per esporsi. Uno sviluppatore potrebbe aver installato un pacchetto legittimo settimane, mesi o addirittura anni prima e successivamente ricevere un'estensione tramite il meccanismo di aggiornamento del pacchetto. Bloom ha trovato che il conteggio totale dei download per i pacchetti vulnerabili superava i 500.000, illustrando la potenziale scala dell'esposizione. L'impatto tecnico è anche significativo. Secondo Bloom, le estensioni di VS Code e le estensioni per IDE compatibili come Cursor, Kiro, Windsurf, Antigravity, VSCodium ed Eclipse Theia funzionano con accesso host Node.js. Possono leggere e scrivere file, generare processi figli e fare richieste di rete in uscita. Un problema di design del marketplace. Le scoperte di Bloom puntano infine a debolezze nel modo in cui i marketplace gestivano dipendenze e spazi dei nomi. L'azienda ha identificato due lacune: i marketplace potrebbero accettare pacchetti contenenti riferimenti a estensioni che non esistevano, e gli spazi dei nomi a cui si fa riferimento da software esistenti potrebbero rimanere disponibili per la registrazione. Insieme, queste condizioni hanno creato un percorso per un attaccante per trasformare un riferimento dormiente in una dipendenza attiva. Il problema non era limitato esclusivamente ai pacchetti di estensioni. Durante la sua indagine, Bloom ha scoperto che le dipendenze delle estensioni Open VSX dichiarate nei manifesti potevano essere esposte allo stesso problema sottostante. Entrambi gli operatori di marketplace hanno risposto dopo la divulgazione. Bloom ha segnalato il problema di Open VSX alla Eclipse Foundation il 5 febbraio 2026 e ha affermato che il team si è mosso rapidamente per proteggere gli spazi dei nomi a rischio e implementare controlli per estensioni e dipendenze inesistenti. Bloom ha segnalato il problema a Microsoft il 17 febbraio. Microsoft inizialmente lo ha classificato come Moderato prima di riaprire il caso dopo che Bloom ha fornito ulteriori prove. Microsoft ha successivamente confermato che le protezioni contro la resurrezione delle estensioni erano state implementate in fasi, con protezioni per azioni degli amministratori risalenti a ottobre 2025 e protezioni per azioni degli utenti completate a giugno 2026. Cosa significa la ricerca per i team di sicurezza. La lezione più ampia dalla ricerca di Bloom riguarda meno una specifica vulnerabilità del marketplace e più come le organizzazioni pensano agli endpoint degli sviluppatori. Le estensioni IDE sono spesso trattate come strumenti di produttività piuttosto che come componenti software che richiedono una continua supervisione della sicurezza. Eppure possono avere accesso profondo ai sistemi su cui lavorano gli sviluppatori, e i pacchetti di estensioni possono moltiplicare il numero di componenti introdotti tramite una singola installazione. Per i team di sicurezza, ciò significa che la visibilità dovrebbe estendersi alle estensioni e ai pacchetti installati, alle loro configurazioni, al comportamento degli aggiornamenti automatici e alle capacità delle singole estensioni. Significa anche riconoscere che un'installazione fidata non è necessariamente uno snapshot permanente di ciò che è in esecuzione su un endpoint. La ricerca di Bloom dimostra come una lacuna apparentemente minore, una dipendenza che punta a qualcosa che non esiste, possa diventare un problema significativo di sicurezza della catena di approvvigionamento quando combinata con installazioni e aggiornamenti automatici. La domanda importante per le organizzazioni potrebbe quindi non essere semplicemente quali estensioni gli sviluppatori hanno approvato, ma quali estensioni i loro ambienti di sviluppo sono in grado di installare senza chiedere nuovamente.