Coder, registry compromesso: moduli Terraform malevoli rubavano credenziali cloud e token AI

Richieste deviate verso server controllati dall’attaccante

L’infrastruttura collegata a registry.coder.com, il registry principale dei moduli Coder, è stata compromessa e utilizzata per distribuire pacchetti Terraform alterati. L’incidente è classificato come Critical, con un punteggio CVSS v4 di 9.0 su 10.

Un attore non identificato ha ottenuto accesso all’infrastruttura Cloudflare di Coder e inserito indirizzi IP non autorizzati nel pool dei server associati al registry. Di conseguenza, Cloudflare ha instradato parte delle richieste degli utenti verso sistemi controllati dall’attaccante anziché verso i server legittimi.

I sistemi ostili riproducevano il funzionamento del registry e fornivano artefatti contenenti codice malevolo. Non tutte le richieste sono necessariamente finite sull’infrastruttura contraffatta: la distribuzione dipendeva dal bilanciamento del traffico tra gli indirizzi presenti nel pool.

La finestra di esposizione è compresa tra le 07:35 UTC e le 21:45 UTC del 31 agosto 2026. L’advisory di sicurezza, pubblicato il 1 settembre 2026 con il titolo “Malicious Packages Served from Unauthorized Registry Server”, indica che ogni deployment che abbia recuperato un modulo in quelle ore deve essere considerato potenzialmente esposto.

La compromissione riguarda un componente delicato della catena di sviluppo. Coder viene impiegato per fornire ambienti cloud di sviluppo sicuri e self-hosted, anche per la costruzione e il deployment di applicazioni di intelligenza artificiale. Tra le organizzazioni indicate come utilizzatrici della piattaforma figurano Dropbox, Palantir, Square, Mercedes-Benz, KKR, EnBW, il governo statunitense e aziende della difesa. Non è noto quali clienti abbiano effettivamente ricevuto i moduli alterati.

Lo stealer nascosto nei moduli Terraform

I pacchetti malevoli agivano come information stealer all’interno dell’ambiente in cui il provisioner eseguiva il codice Terraform. L’obiettivo era raccogliere credenziali e configurazioni utilizzabili per accedere a infrastrutture cloud, pipeline di sviluppo e servizi esterni.

Il codice cercava, tra gli altri elementi:

• variabili d’ambiente e segreti disponibili sul provisioner;
• chiavi API dei provider cloud;
• chiavi API per strumenti di intelligenza artificiale;
• credenziali CI/CD;
• segreti salvati nei file di configurazione;
• cronologia del terminale;
• token OIDC degli utenti;
• chiavi SSH configurate;
• token monouso per provider di autenticazione esterni;
• password del database Coder;
• configurazioni accessibili quando il provisioner era eseguito dentro coderd.

Le informazioni raccolte venivano inviate a coder-infra[.]com, dominio scelto per apparire compatibile con l’infrastruttura legittima di Coder. L’indirizzo indicato nell’advisory è www[.]coder-infra[.]com, che sarebbe stato registrato il 28 agosto 2026.

La quantità di dati raggiungibili variava in base all’operazione eseguita. Durante il caricamento, l’aggiornamento o il dry run di un template, il provisioner non riceveva i segreti e le informazioni personali dell’utente. Restavano però esposti i valori già presenti sul provisioner, comprese variabili d’ambiente e credenziali locali.

Il rischio aumentava durante la build di un workspace. In questo scenario il provisioner poteva ricevere il token OIDC dell’utente, la relativa chiave SSH se configurata e i token dei provider esterni abilitati per quel template. Questi ultimi erano monouso; i refresh token, secondo Coder, non venivano trasmessi.

Se il provisioner operava all’interno di coderd, il codice ostile poteva inoltre raggiungere la password del database e altre impostazioni sensibili della piattaforma. La compromissione poteva quindi propagarsi oltre il singolo workspace.

Deployment e versioni esposti

Sono interessate tutte le versioni di Coder precedenti alla 2.37.0. Le release contenenti le correzioni sono:

• 2.37.0
• 2.36.4
• 2.35.7
• 2.34.9

L’aggiornamento può quindi essere effettuato alla versione più recente oppure alla release corretta del ramo supportato in uso. L’incidente non ha un identificativo CVE.

Un deployment può essere stato coinvolto se ha scaricato un modulo da registry.coder.com durante la finestra di esposizione. Ciò accade soprattutto durante la creazione di un nuovo template o di una sua nuova versione.

Anche la creazione di un workspace può provocare un nuovo download, ma principalmente quando la cache dei moduli è disabilitata nelle impostazioni del template. La cache risulta abilitata per impostazione predefinita. Tuttavia, un workspace può essere stato costruito successivamente utilizzando una versione di template nella quale il modulo alterato era già stato memorizzato.

Questo rende insufficiente il solo aggiornamento del software. Un pacchetto malevolo rimasto nella cache può continuare a essere utilizzato durante nuove distribuzioni, nonostante il registry abbia ripreso a servire contenuti legittimi.

Coder ha esaminato le versioni dei template attualmente disponibili e le ha dichiarate prive del codice ostile. Non risultano indicazioni di accesso ai dati dei clienti conservati direttamente dall’azienda. La ricostruzione, però, non può essere considerata completa: i server malevoli erano esterni al controllo di Coder e i relativi log non sono interamente disponibili.

Indicatori da cercare nei log e nei template

Le organizzazioni devono controllare log DNS, firewall, proxy e flussi VPC alla ricerca di connessioni in uscita verso il dominio di esfiltrazione. Gli indicatori di rete principali sono:

• dominio: www[.]coder-infra[.]com;
• indirizzo IP: 199.91.220[.]205;
• URL: http://www[.]coder-infra[.]com/cli/check;
• header HTTP: X-CLI-Token: your-secret-token.

Nei file Terraform va cercato un blocco data "external" "telemetry" che esegue ${path.module}/dlp-docker.sh. Nei log dei job dei provisioner, la stringa più utile per l’individuazione è:

data.external.telemetry

Gli hash SHA-256 dei file segnalati sono:

File	SHA-256
dlp-docker.sh	7190a17c593276d7fd71c4863a4bc0b6c957ed14249288e6f64c5540e2c49398
dlp.sh comune	a7f4fa5f7e33b2a6f6488cf28444584caa449144d246b083de919162f5514247
dlp.sh per Aider	414d01f6072fbf05bef513e277f4c2b504a413c8e2aa5bae133a5cbc0cda9dc1
dlp.sh per RStudio Server	a64ce3038f2a501c9735abf6a1f9f04cbddbad53371cd68bec0f7510365c8ffa
dlp.sh per Windows RDP	ebbe0d2ed8cfaf9e19edb38ce44d6b407f9771b5c0813a7add27c05f66e89596
dlp.sh per Zed	7ef6b8c3c976fb60b3fa22e9e294ba548d9b532e060c1323a0124a3a7a647f13

L’assenza di questi hash non esclude automaticamente l’esposizione. Le verifiche temporali sui moduli scaricati e sui workspace che li hanno usati rimangono necessarie.

Come individuare e rimuovere i moduli dalla cache

Coder ha predisposto query SQL per identificare i file di modulo creati nella finestra dell’incidente. I criteri comprendono l’identificativo nullo 00000000-0000-0000-0000-000000000000, il MIME type application/x-tar e un orario di creazione compreso tra 2026-08-31 07:35:00+00 incluso e 2026-08-31 21:45:00+00 escluso.

Le ricerche collegano le tabelle dei file, dei valori Terraform, delle versioni dei template e dei template stessi. Consentono di ricavare nome e versione del template, ID del modulo, momento della memorizzazione in cache e workspace che hanno utilizzato il componente.

Una ricerca separata, denominata SearchLogsForKeyPhrase, esamina i log dei provisioner per data.external.telemetry. I risultati includono job, build, workspace, template, proprietario o iniziatore, stato e orario di avvio.

I moduli sospetti devono essere eliminati prima di distribuire nuovamente i template. La procedura ufficiale crea una tabella temporanea con gli ID individuati, azzera i riferimenti cached_module_files, elimina i file dalla tabella files ed esegue tutto in una transazione BEGIN/COMMIT.

Patch e rotazione delle credenziali

La risposta deve seguire un ordine preciso: individuare i moduli coinvolti, cancellarli dalla cache e aggiornare Coder a 2.37.0, 2.36.4, 2.35.7 o 2.34.9. Coder stava inoltre preparando una release successiva dotata di procedure automatiche di remediation.

Tutte le credenziali potenzialmente accessibili ai provisioner devono essere ruotate in modo proattivo. La priorità comprende chiavi cloud, token per servizi AI, credenziali CI/CD, segreti nelle variabili d’ambiente, chiavi SSH, token OIDC e password del database Coder.

Vanno considerate anche le credenziali presenti nei file di configurazione o nella cronologia della shell. Non poter dimostrare un’esfiltrazione non equivale a escluderla: la mancanza dei log completi dei server ostili impedisce una verifica conclusiva per ogni deployment.