Violazione OpenCode: blocca le chiavi con Synthorai Trusted IPs

Il 17 ottobre 2026, OpenCode ha comunicato agli utenti che un intruso aveva avuto accesso a un sistema legacy di OpenCode Console, il suo servizio ospitato, e che le chiavi di provider esterni salvate al suo interno «potrebbero essere state esposte». Gli utenti hanno poi segnalato addebiti da qualche centinaio di dollari fino a $1,700 sui propri account OpenAI, Anthropic e Google. Una chiave del provider è la chiave API rilasciata da servizi come OpenAI o Anthropic. Salvarla in uno strumento ospitato, perché possa chiamare il provider per conto dell’utente, è la pratica detta BYOK (bring your own key). Il costo di una chiave rubata dipende da due fattori: da dove può essere usata e quanto può spendere prima di essere bloccata.

TL;DR

• Secondo OpenCode, la violazione di Console ha coinvolto l’1.4% degli utenti di Console; le chiavi salvate nella CLI locale di OpenCode non sono state interessate.
• Le regole IP e i limiti di spesa di un gateway vedono solo il traffico che lo attraversa. Per una chiave del provider rubata serve quindi un limite vincolante presso il provider.
• Con “Approvazione dei nuovi IP” attivo, Synthorai rifiuta le chiamate effettuate con una chiave API da indirizzi non approvati per quella chiave, restituendo HTTP 403 e ip_not_trusted.
• Ogni chiave Synthorai può avere un limite di spesa, limiti al numero di richieste e token al minuto e una data di scadenza.

Che cosa è successo nella violazione di OpenCode Console?

Un soggetto non autorizzato ha avuto accesso a «un sistema legacy che stavamo dismettendo», come riportato nell’email di OpenCode agli utenti coinvolti. Potrebbe quindi aver letto le chiavi dei provider salvate nei loro workspace di Console. OpenCode ha indicato il 17 ottobre alle 00:30 UTC come primo momento di possibile esposizione. Questa è la sequenza degli eventi ricostruita dai post di OpenCode, dagli interventi del personale dei provider e dalla stampa:

Un attacco di distillazione usa le risposte di un modello, raccolte su larga scala, per addestrarne un altro. Le chiavi rubate sono uno dei modi con cui queste operazioni pagano le chiamate. OpenCode non ha spiegato il legame tra la violazione e la distillazione. Il cofondatore Dax Raad ha dichiarato che la violazione riguardava «OpenCode Console, non OpenCode in sé» e che le chiavi aggiunte nella CLI locale non arrivano mai all’azienda. Al 21 ottobre, OpenCode non aveva pubblicato la causa della violazione, informazioni sulla cifratura delle chiavi salvate, il numero di account corrispondente all’1.4%, una politica di rimborso o un’analisi post-mortem (The Hacker News, BleepingComputer).

Quali chiavi sono state esposte e quali controlli servono?

Le chiavi esposte erano chiavi dei provider. Una chiave di questo tipo, una volta rubata, viene usata direttamente contro il provider, senza passare dallo strumento che la conservava. Questo limita ciò che può fare un gateway LLM. Un gateway è un servizio interposto tra il codice e i provider dei modelli, a cui inoltra le richieste: può vedere e limitare solo il traffico che lo attraversa. Occorre quindi distinguere i due tipi di chiave:

Trusted IPs e i limiti di spesa, descritti nelle prossime due sezioni, proteggono le chiavi della prima riga. Per quelle della seconda riga, l’ultima protezione è il limite vincolante impostato su OpenAI, Anthropic o Google; la sezione successiva riporta le relative impostazioni.

Come protegge Synthorai le chiavi della piattaforma e le chiavi BYOK?

Le chiavi dei provider aggiunte al vault BYOK vengono cifrate a riposo con AES-256-GCM, un algoritmo standard di cifratura autenticata. Dopo il salvataggio, nessuna API, strumento MCP o pagina della console le restituisce: la console mostra solo gli ultimi quattro caratteri. Il gateway decifra una chiave solo in memoria, per la richiesta che la usa, e solo il proprietario del workspace può aggiungerla, ruotarla o rimuoverla. Le chiavi dei provider usate da Synthorai per la propria capacità sono conservate nello stesso modo e non vengono mostrate da nessuna pagina della console o API, nemmeno nella console di amministrazione. La cifratura protegge le copie del database; un servizio in esecuzione compromesso può comunque accedere alle chiavi mentre vengono usate. Per questo, l’ultima protezione delle chiavi BYOK resta il limite lato provider descritto più avanti.

Le chiavi API che Synthorai ti rilascia vengono conservate solo come hash, un’impronta unidirezionale da cui non è possibile ricostruire la chiave. La chiave completa viene mostrata una sola volta, alla creazione. Ogni lettura successiva, dalla console, dall’API di gestione o dal server MCP, restituisce solo il prefisso. Una chiave di inferenza può soltanto chiamare i modelli: l’API di gestione la rifiuta, quindi chi la ruba non può leggere log, dati di utilizzo o altre chiavi (API keys, admin keys).

Come fa Trusted IPs a bloccare una chiave rubata?

IP attendibili rifiuta le chiamate effettuate con una chiave API da qualsiasi indirizzo non approvato per quella chiave. Una chiave copiata da un log CI o da un laptop restituisce quindi un errore, anziché una risposta, se viene usata altrove. Il proprietario o un amministratore attiva la funzione in Impostazioni › Sicurezza con “Approvazione dei nuovi IP”. La finestra elenca gli indirizzi da cui è stata usata ciascuna chiave negli ultimi sette giorni, tutti già selezionati per l’approvazione. Controlla l’elenco prima di confermare e deseleziona gli indirizzi che non riconosci: se una chiave è già stata rubata e usata, nell’elenco comparirà anche l’indirizzo dell’attaccante.

Da quel momento, una chiamata da un nuovo indirizzo restituisce HTTP 403 (l’indirizzo qui riportato è un esempio riservato alla documentazione):

{
  "error": {
    "type": "permission_error",
    "code": "ip_not_trusted",
    "ip": "203.0.113.9",
    "message": "Requests from IP address 203.0.113.9 are held until this address is approved for the key. ...",
    "approve_url": "https://synthorai.io/console/settings?tab=security"
  }
}

Chi ha creato la chiave riceve un’email con l’indirizzo, la posizione, il client e il modello richiesto. L’approvazione avviene nella console dopo l’accesso, quindi inoltrare l’email non approva nulla. Per un client che cambia indirizzo si può approvare un singolo indirizzo oppure la sua rete /24 (256 indirizzi IPv4 contigui). Il gateway ricava l’indirizzo del chiamante dalla connessione vista dai propri proxy. Un client non può quindi spacciarsi per un altro indirizzo inviando un proprio header X-Forwarded-For, l’header usato dai proxy per trasmettere l’indirizzo originale del client. Lo abbiamo verificato con un header contraffatto: il rifiuto riportava comunque l’indirizzo reale.

# From an address not yet approved for the key, with a forged header:
curl -s https://synthorai.io/v1/models \
  -H "Authorization: Bearer $SYNTHORAI_API_KEY" \
  -H "X-Forwarded-For: 203.0.113.9"
# The 403's "ip" field is the caller's real address, not 203.0.113.9.

Una chiave può anche essere creata con un ip_allowlist fisso, ma quell’elenco fa parte delle impostazioni della chiave: ogni nuovo ufficio, server o punto di uscita VPN richiede una modifica, e una voce dimenticata resta autorizzata. Trusted IPs parte dagli indirizzi da cui la chiave viene già usata, chiede conferma prima di autorizzarne uno nuovo e raccoglie gli indirizzi di tutte le chiavi in un unico elenco, da cui basta un clic per autorizzare un indirizzo noto. Se una chiave ha una propria allowlist, decide soltanto quell’elenco: per ciascuna chiave usa una modalità oppure l’altra.

L’autorizzazione vale per la singola chiave. Le funzioni serverless e i runner CI che usano un indirizzo nuovo a ogni esecuzione verrebbero bloccati ogni volta. Non autorizzare gli intervalli pubblicati da un provider di CI ospitata: sono condivisi da tutti i suoi clienti, quindi chiunque esegua un job su quel servizio supererebbe il controllo. Fai passare queste chiamate da un indirizzo di uscita fisso, per esempio tramite un runner autogestito o un NAT gateway, e autorizza quell’indirizzo. In alternativa, assegna una chiave di breve durata con un limite basso.

Come limitano la spesa i limiti applicati a una chiave rubata?

Ogni chiave API Synthorai può avere un proprio limite di spesa. Anche se viene rubata, si ferma alla soglia che hai scelto. Alla creazione della chiave, la console permette di impostare il limite, i modelli consentiti e la scadenza:

I limiti di frequenza per chiave e le altre impostazioni qui sotto si configurano tramite l’API di gestione:

Ecco una chiave dedicata a un servizio, limitata alle sue necessità e creata con una chiave amministrativa (una chiave di gestione che può creare chiavi e impostarne i limiti, ma non chiamare modelli):

curl https://synthorai.io/api/v1/keys \
  -H "Authorization: Bearer sk-syn-admin-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "support-bot prod",
    "limit_usd": 50,
    "limit_reset": "daily",
    "rate_limit": {"rpm": 60, "tpm": 200000},
    "allowed_models": ["claude-haiku-5-5"],
    "expires_at": "2027-01-31T00:00:00Z"
  }'

I proprietari del workspace possono anche impostare un tetto di spesa giornaliero e mensile per ogni membro. Un membro che raggiunge il tetto mensile riceve HTTP 402 fino al mese successivo. Questi limiti si applicano al traffico che passa da Synthorai. Se il BYOK viene conteggiato nel limite, coprono anche le richieste BYOK effettuate tramite il gateway, ma non una chiave del provider rubata e usata direttamente.

Che cosa non bloccano questi controlli?

Trusted IPs blocca una chiave usata da un indirizzo nuovo, ma non interviene se viene usata da una macchina attendibile. I furti più comuni avvengono proprio lì: malware sul laptop di uno sviluppatore, un job CI compromesso o un server indotto a inviare richieste per conto di un attaccante. In questi casi, a contenere i danni sono il limite di spesa della chiave, l’elenco dei modelli consentiti e una scadenza breve.

L’approvazione dipende da una persona: un attaccante può quindi generare una richiesta in attesa e sperare che venga approvata per abitudine. La pagina di approvazione mostra l’indirizzo, la posizione, il client e il modello. Approva solo se corrispondono a una tua chiamata.

Un limite di spesa con azzeramento giornaliero permette a una chiave rubata di spendere fino a quella soglia ogni giorno, finché qualcuno non se ne accorge. Ai limiti affianca il rilevamento degli abusi: l’email per ogni indirizzo in attesa di approvazione, la spesa per chiave nella console e il log di audit delle modifiche alle chiavi. Se sospetti che una chiave sia stata rubata, eliminala dalla console e creane una nuova. Per intercettare le chiavi prima che vengano esposte, aggiungi nel servizio che ospita il codice una regola di scansione dei segreti per il prefisso sk-syn-, per esempio un pattern personalizzato di GitHub con protezione dei push.

Che cosa impostare presso il provider per una chiave BYOK?

Assegna a ogni strumento una chiave del provider dedicata, in un progetto o workspace separato, con un limite di spesa vincolante. Così una singola chiave rubata può consumare solo il budget di quel progetto. Revoca la chiave rubata nella dashboard del provider: eliminarla dallo strumento che la conservava non la revoca. Nessuno dei tre provider permette di impostare limiti su una singola chiave; l’unità minima è il progetto o il workspace:

Gli avvisi di spesa e i budget che si limitano a inviare email non fermano un attacco in corso. Restano utili come secondo segnale, insieme a un limite vincolante. Nella pagina BYOK della console Synthorai, sotto le chiavi, trovi i link alle impostazioni dei limiti di ciascun provider:

Si può usare OpenCode con Synthorai?

Sì. Le chiavi usate dalla CLI locale di OpenCode restano sulla tua macchina, una configurazione non coinvolta nella violazione. opencode auth login https://synthorai.io autentica OpenCode tramite il browser con un codice monouso. OpenCode riceve una propria chiave API che scade dopo 7, 30 o 90 giorni (guida alla configurazione). Se “Approvazione dei nuovi IP” è attivo e autorizzi l’accesso dalla stessa rete, l’indirizzo da cui hai effettuato l’accesso viene automaticamente autorizzato per quella chiave; le chiamate da altri indirizzi restano in attesa di approvazione. Se la richiesta di accesso proviene da una rete diversa da quella del browser, la pagina di conferma ti avvisa e l’indirizzo non viene autorizzato finché non approvi la prima chiamata. Se non hai eseguito tu il comando, annulla la richiesta.

La chiave compare nella pagina delle chiavi API con il nome “OpenCode”, dove puoi aggiungere un limite di spesa o eliminarla. Una chiave salvata su un laptop può comunque essere rubata da un malware presente sul dispositivo. Scegli quindi una chiave da 7 o 30 giorni e lascia attivo “Approvazione dei nuovi IP”: una copia della chiave non funzionerà da altri indirizzi e scadrà a breve.

Domande frequenti

Le chiavi salvate nella CLI di OpenCode sono state esposte nella violazione?

No. OpenCode ha dichiarato che la violazione era limitata a OpenCode Console. Le chiavi aggiunte nella CLI locale o nell’app desktop sono conservate sulla macchina dell’utente e non vengono mai inviate a OpenCode.

Eliminare una chiave del provider da uno strumento ospitato la revoca?

No. Eliminare una chiave da uno strumento rimuove solo la copia conservata dallo strumento. La chiave continua a funzionare presso il provider finché non la revochi nella sua dashboard e ne crei una nuova.

Il limite di spesa di un gateway protegge una chiave del provider rubata?

No. I limiti di un gateway conteggiano solo le richieste che lo attraversano. Una chiave del provider rubata viene usata direttamente contro il provider, quindi si applica soltanto il limite di spesa del provider stesso.

Approfondimenti: IP attendibili, vault BYOK, chiavi amministrative e limiti delle chiavi, configurazione di OpenCode.

Fonti consultate il 21 ottobre 2026: post ed email di OpenCode riportati dalla stampa, post del personale dei provider e documentazione dei provider collegata sopra. La verifica con l’header contraffatto è stata eseguita sul gateway di produzione di Synthorai il 21 ottobre 2026.

← Torna al blog