Una vulnerabilità Windows appena scoperta (CVE-2026-35603) consente a qualsiasi utente non amministratore di inserire un file di configurazione malevolo nella cartella condivisa C:\ProgramData, dove diversi assistenti di programmazione basati su IA leggono automaticamente le impostazioni. Quando un amministratore avvia successivamente uno di questi strumenti — Claude Code, Cursor, Codex CLI o Gemini CLI — il file malevolo viene eseguito con privilegi di sistema completi, dando all'attaccante il controllo della macchina senza alcun preavviso.

Perché il problema è importante

Gli assistenti di programmazione basati su IA sono diventati comuni nelle pipeline di sviluppo, spesso eseguiti con privilegi elevati per accedere a compilatori, gestori di pacchetti o repository interni. La capacità di iniettare codice che viene eseguito come amministratore bypassa il consueto sandbox a livello utente che protegge una workstation. In pratica, un account con privilegi limitati potrebbe piazzare un file, attendere che un amministratore avvii l'assistente e poi far eseguire all'assistente comandi arbitrari, alterare file di sistema o sottrarre credenziali. L'impatto spazia da un punto di appoggio silenzioso per malware persistenti fino al completo controllo delle workstation aziendali.

Come funziona la vulnerabilità

Tutti e quattro gli strumenti condividono una semplice scelta progettuale: memorizzano la configurazione a livello di macchina in C:\ProgramData e caricano automaticamente tali file all'avvio. Su Windows, quella directory è leggibile e scrivibile da qualsiasi utente standard. Gli strumenti non verificano il proprietario o l'integrità dei file prima di analizzarli.

Strumento File di configurazione previsto
Claude Code managed-settings.json
Cursor hooks.json
Codex CLI config.toml
Gemini CLI system-defaults.json

Un attaccante crea un file con il nome esatto cercato dallo strumento, lo posiziona nella cartella corrispondente sotto C:\ProgramData e attende. Quando un amministratore apre l'assistente, il programma legge il file controllato dall'attaccante ed esegue il suo contenuto. Nel caso di Codex CLI, la configurazione malevola può anche disattivare i sandbox di sicurezza integrati, ampliando ulteriormente la superficie di attacco.

Anthropic, il produttore di Claude Code, ha già spostato le proprie impostazioni in una posizione protetta, chiudendo di fatto la falla per quel prodotto. Gli altri fornitori non hanno rilasciato una correzione al momento del rapporto di ricerca, lasciando i propri utenti esposti.

Chi vince e chi perde

  • Gli attaccanti ottengono un percorso diretto di escalation dei privilegi che non richiede l'exploit di bug del kernel o codice zero-day.
  • Sviluppatori e organizzazioni che si affidano a questi assistenti per il lavoro quotidiano affrontano il rischio di furto silenzioso di credenziali, iniezione di codice o distribuzione di ransomware.
  • I fornitori di strumenti rischiano danni reputazionali e possibili responsabilità legali se la falla non viene corretta tempestivamente.

Il costo di una violazione può essere elevato: chiavi SSH compromesse, token cloud e credenziali Git possono aprire la porta a una compromissione più ampia della rete. Anche una singola workstation compromessa può diventare un trampolino di lancio per il movimento laterale all'interno di un ambiente aziendale.

Passaggi di mitigazione che puoi adottare oggi stesso

Finché i fornitori non rilasceranno le patch, gli amministratori possono mettere in sicurezza le cartelle stesse. I seguenti comandi PowerShell, eseguiti con privilegi elevati, creano le directory previste (se non esistono già) e le bloccano in modo che solo il sistema e gli amministratori abbiano l'accesso in scrittura:

# Create the directories
$paths = @(
    "C:\ProgramData\ClaudeCode",
    "C:\ProgramData\Cursor",
    "C:\ProgramData\openai\codex",
    "C:\ProgramData\gemini-cli"
)
foreach ($p in $paths) { New-Item -ItemType Directory -Path $p -Force }

# Remove inherited permissions and grant only the needed accounts
foreach ($p in $paths) {
    icacls $p /inheritance:r
    icacls $p /grant "SYSTEM:(OI)(CI)F" "Administrators:(OI)(CI)F" "Users:(OI)(CI)RX"
}

Dopo aver applicato le ACL (liste di controllo degli accessi), scansiona le cartelle alla ricerca di file di proprietà di un utente standard. Il ritrovamento di un tale file è un forte indicatore che la macchina è già stata compromessa; in tal caso, ruota immediatamente tutte le chiavi private, i token di accesso cloud e le credenziali di controllo versione.

Cosa monitorare

  • Patch dei fornitori – Tieni d'occhio le note di rilascio dei fornitori interessati. Il passaggio a una posizione protetta o un controllo di integrità per i file di configurazione neutralizzerebbe il problema.
  • Aggiornamenti degli strumenti di sicurezza – Le piattaforme di rilevamento degli endpoint potrebbero aggiungere firme per questo specifico schema di creazione file in C:\ProgramData. L'implementazione di tali aggiornamenti può fornire avvisi precoci.
  • Divulgazioni della community – I ricercatori di sicurezza potrebbero pubblicare exploit proof-of-concept o script di rilevamento che possono essere incorporati nel monitoraggio interno.

Controargomentazione

Alcuni potrebbero sostenere che il rischio sia limitato alle macchine in cui esistono più account utente, o che gli strumenti vengano raramente eseguiti con privilegi di amministratore. Sebbene tali fattori riducano la superficie di attacco, non la eliminano. Molti laptop aziendali sono gestiti centralmente e spesso concedono diritti di amministratore agli sviluppatori per l'installazione di compilatori o SDK. Inoltre, i malware possono sfruttare la stessa cartella per persistere su un sistema anche senza un trigger a livello di amministratore, utilizzando l'assistente AI semplicemente come un comodo vettore di esecuzione.

Punti chiave

CVE-2026-35603 dimostra come una decisione progettuale apparentemente innocua — leggere la configurazione da una cartella scrivibile da tutti — possa diventare un potente percorso di escalation quando sono coinvolti strumenti di IA. Finché i vendor non risolveranno la falla, l'unica difesa affidabile consiste nel bloccare le sottocartelle di C:\ProgramData utilizzate da questi assistenti e nel trattare qualsiasi file inaspettato presente in esse come un segno di compromissione. Ignorare il problema lascia una linea diretta affinché account con privilegi bassi possano ottenere il pieno controllo di una workstation Windows.