Koi blocca malware negli IDE AI Cursor e Windsurf sfruttando le falle dei namespace OpenVSX

0

Koi ha bloccato una classe di attacchi malware che colpiva in modo silenzioso gli IDE basati su intelligenza artificiale, sfruttando un’eredità pericolosa di configurazioni di VSCode e proteggendo ambienti come Cursor, Windsurf e Google Antigravity da estensioni malevole distribuite tramite OpenVSX. L’intervento ha messo in luce una vulnerabilità strutturale nella supply chain degli strumenti di sviluppo AI, dove raccomandazioni automatiche hardcoded e namespace non rivendicati hanno creato un vettore di attacco ad alto impatto per milioni di sviluppatori.

Koi e la mitigazione proattiva dei namespace vulnerabili

Koi ha individuato il problema analizzando il comportamento di diversi fork open source di VSCode che integrano funzionalità di AI per la scrittura e l’analisi del codice. Questi ambienti, nati per accelerare la produttività degli sviluppatori, hanno ereditato configurazioni progettate originariamente per l’ecosistema Microsoft Visual Studio Code, incluse le raccomandazioni proattive di estensioni basate su file aperti o software rilevato sul sistema.

Il nodo critico risiede nel fatto che tali raccomandazioni puntano al marketplace ufficiale Microsoft, che però non è accessibile legalmente ai fork open source. In assenza di una revisione profonda, gli IDE ricadono automaticamente su OpenVSX, il marketplace gestito dalla Eclipse Foundation. Qui, numerosi namespace storicamente associati a estensioni Microsoft risultavano non rivendicati. Questo vuoto ha aperto la porta a un attacco semplice ma devastante: registrare quei namespace e caricare estensioni apparentemente legittime ma in realtà malevole.

Koi ha scelto una strategia difensiva inedita e radicale. Invece di limitarsi a segnalare il problema, ha rivendicato direttamente i namespace critici su OpenVSX e vi ha caricato estensioni placeholder innocue, prive di funzionalità e chiaramente identificate come misure di prevenzione. In questo modo ha impedito agli attaccanti di occupare quegli spazi e ha bloccato sul nascere la distribuzione di malware tramite raccomandazioni automatiche.

Il dato più allarmante è emerso subito dopo: i placeholder hanno accumulato oltre mille installazioni in poche settimane. Questo numero non indica un errore tecnico, ma dimostra la fiducia cieca degli sviluppatori nei suggerimenti dell’IDE, che vengono installati spesso senza verifiche manuali. È la prova empirica di quanto questo vettore di attacco fosse non solo teorico, ma già pronto per essere sfruttato su larga scala.

Cursor e l’eredità rischiosa delle raccomandazioni di VSCode

Cursor è uno degli esempi più emblematici di come l’innovazione rapida nel settore degli IDE AI possa amplificare rischi strutturali. Basato su VSCode e arricchito con funzionalità di intelligenza artificiale avanzata, Cursor ha raggiunto oltre un milione di utenti attivi giornalieri e una valutazione stimata di 9,08 miliardi di euro. Questa crescita vertiginosa ha però mantenuto inalterate alcune configurazioni hardcoded, comprese le raccomandazioni proattive di estensioni.

In pratica, l’apertura di file come azure-pipelines.yaml o la rilevazione di software come PostgreSQL sul sistema attiva automaticamente suggerimenti per estensioni specifiche. In un contesto chiuso e controllato come il marketplace Microsoft, questo meccanismo è relativamente sicuro. In un fork open source che si appoggia a OpenVSX, diventa invece un vettore di supply chain attack.

Un’estensione installata tramite queste raccomandazioni ottiene gli stessi privilegi di qualsiasi plugin VSCode: accesso al filesystem, capacità di eseguire codice, comunicare in rete e interagire con processi locali. Un’estensione malevola può quindi estrarre chiavi SSH, credenziali AWS, token di accesso e codice sorgente proprietario, inviandoli a server remoti senza che l’utente se ne accorga.

Koi ha segnalato questo scenario direttamente al team di Cursor nel novembre 2025, utilizzando i canali di sicurezza ufficiali. Tuttavia, secondo la divulgazione pubblica, non è arrivata alcuna risposta. Questo silenzio prolunga l’esposizione e sottolinea una criticità diffusa nel settore: la velocità di sviluppo e la pressione del mercato AI spesso superano la maturità dei processi di sicurezza.

Windsurf e la crescita accelerata degli IDE AI

Windsurf segue una traiettoria simile. Anch’esso basato su VSCode e arricchito con funzioni di intelligenza artificiale, Windsurf ha raggiunto circa un milione di utenti in tempi estremamente rapidi. La sua integrazione in un ecosistema AI più ampio, culminata nell’acquisizione da parte di Google per 2,20 miliardi di euro, ha portato visibilità e risorse, ma non ha risolto automaticamente i problemi ereditati.

Le stesse raccomandazioni hardcoded e il fallback su OpenVSX hanno esposto Windsurf allo stesso rischio di namespace hijacking. Koi ha incluso Windsurf nelle segnalazioni di sicurezza, contattando il team attraverso gli indirizzi ufficiali. Anche in questo caso, non è stata registrata una risposta pubblica prima della divulgazione coordinata.

Questo scenario evidenzia un problema sistemico: i fork di VSCode, soprattutto quelli orientati all’AI, condividono una base comune che non è stata progettata per un ecosistema frammentato di marketplace. Senza un audit approfondito delle configurazioni ereditate, ogni nuovo IDE AI rischia di replicare gli stessi punti deboli, moltiplicando l’impatto potenziale di un singolo vettore di attacco.

Google Antigravity e il fix parziale

Google Antigravity rappresenta il caso più recente e simbolico. Lanciato come parte dell’espansione di Google nel settore degli strumenti di sviluppo AI, Antigravity eredita anch’esso l’architettura VSCode e, con essa, le raccomandazioni proattive problematiche. Koi ha segnalato la vulnerabilità a Google il 23 novembre 2025.

La risposta iniziale è stata negativa: il problema è stato classificato come “non risolvibile”. Solo dopo ulteriori dettagli tecnici e la dimostrazione del vettore di attacco, Google ha riaperto il ticket e implementato un fix parziale. Tra il 26 dicembre 2025 e il 1 gennaio 2026, sono state rimosse 13 estensioni da OpenVSX ritenute pericolose.

Questo intervento ha ridotto il rischio immediato, ma non ha eliminato la causa strutturale: le raccomandazioni hardcoded che puntano a namespace non garantiti. Senza una revisione architetturale più profonda, il problema può ripresentarsi con nuovi namespace o nuove estensioni.

OpenVSX ed Eclipse Foundation: il ruolo del marketplace

OpenVSX è il perno di questa vicenda. Nato per offrire un marketplace aperto e vendor-neutral per le estensioni VSCode, è gestito dalla Eclipse Foundation. La sua apertura, che è un punto di forza per l’ecosistema open source, diventa un rischio quando namespace storicamente associati a vendor commerciali non vengono rivendicati. Koi ha collaborato direttamente con la Eclipse Foundation a partire dal 26 novembre 2025, verificando le configurazioni degli IDE coinvolti e rimuovendo contributori non ufficiali da alcuni namespace sensibili. Questa collaborazione ha rafforzato la sicurezza immediata del marketplace, ma ha anche evidenziato la necessità di politiche più stringenti sulla registrazione dei namespace “storici” o ad alta fiducia. In un contesto in cui le estensioni sono parte integrante della catena di fornitura del software, OpenVSX non è più un semplice repository, ma un’infrastruttura critica. Ogni falla nei suoi meccanismi di governance si traduce in un rischio diretto per organizzazioni e sviluppatori.

Il motore di rischio agentic AI di Koi

Oltre alla mitigazione dei namespace, Koi ha sviluppato un motore di rischio basato su agentic AI che monitora il comportamento delle estensioni post-installazione. Questo approccio va oltre la prevenzione statica e analizza in tempo reale richieste di rete, accessi al filesystem ed esecuzione di script, individuando pattern anomali che indicano attività malevole.

Questo tipo di monitoraggio è cruciale in un ecosistema in cui le difese tradizionali falliscono. Le estensioni VSCode operano spesso in un perimetro fidato e sfuggono ai controlli endpoint classici. Il motore di Koi fornisce visibilità e governance sul codice di terze parti, un aspetto sempre più centrale per le organizzazioni che sviluppano software critico.

Domande Frequenti su Koi