The Pulse

Strix afferma che il suo agente di IA ha trovato il token di amministratore GitHub di Baseten in 25 minuti

Strix afferma che il suo agente di sicurezza autonomo ha trovato un token di accesso personale GitHub attivo in un’immagine Docker di Baseten scaricabile pubblicamente. Il token consentiva l’accesso amministrativo e in scrittura ai reposito

AI.info Team · 2026-09-16

Strix afferma che il suo agente autonomo per la sicurezza ha impiegato circa 25 minuti per trovare un token di accesso personale GitHub attivo con privilegi di amministratore nell’immagine Docker di Baseten, scaricabile pubblicamente. In seguito, il team di sicurezza di Baseten ha classificato il problema come critico, limitato l’accesso al progetto del registro esposto e ruotato il token entro il pomeriggio successivo, secondo la divulgazione di Strix pubblicata il 1 settembre.

«Circa 25 minuti dopo, aveva un token GitHub attivo con privilegi di amministratore a livello di repository nei repository interni di Baseten», ha scritto Alex Schapiro nel resoconto del test pubblicato dall’azienda. Strix stava valutando Baseten come provider di inferenza e ha scansionato *.baseten.co senza credenziali né accesso al codice sorgente.

Un progetto Harbor pubblico esponeva più dei soli metadati delle immagini

La scansione è iniziata con una ricognizione dell’infrastruttura di Baseten esposta a Internet. Strix afferma di aver trovato un registro di container Harbor all’indirizzo gcp-us-east4-zlw.registry.baseten.co, dove un progetto era configurato come pubblico.

L’agente poteva elencare i repository senza autenticarsi, ottenere token anonimi per scaricarli e scaricare manifest e blob delle immagini. Una delle immagini disponibili era baseten/baseten-app. Strix non ha considerato la sola esposizione del registro come prova di una vulnerabilità grave; ha scaricato l’immagine per determinare se il suo contenuto comportasse un rischio maggiore.

La prima credenziale trovata era una coppia di chiavi AWS. Una verifica dell’identità in sola lettura ha restituito InvalidClientTokenId, dimostrando che quelle chiavi non erano più utilizzabili. Strix ha continuato a esaminare i livelli e la configurazione dell’immagine, invece di fermarsi alla credenziale non più valida.

La credenziale attiva era nella cronologia di build di Docker

Strix afferma di aver trovato una seconda credenziale eseguendo TruffleHog e ispezionando direttamente la configurazione dell’immagine. Il token compariva nel campo history[].created_by, dove Docker aveva registrato un comando di build contenente il valore espanso di GITHUB_TOKEN.

La distinzione è importante perché le immagini Docker includono dati di configurazione e cronologia di build, oltre ai livelli del filesystem. Rimuovere una credenziale da un file non elimina un’altra copia registrata nei metadati di build dell’immagine. La documentazione di Docker avverte che gli argomenti di build e le variabili d’ambiente non sono adatti ai segreti, perché possono persistere nell’immagine finale, e raccomanda invece l’uso temporaneo di mount per segreti o SSH.

Strix ha verificato la credenziale con una richiesta GitHub GET /user in sola lettura. GitHub ha risposto con esito positivo, identificando l’account come basetenbot. Strix afferma che il passaggio di build dell’immagine che aveva esposto il token risaliva al 3 marzo 2023, mentre la credenziale era ancora attiva quando l’azienda l’ha trovata nel luglio 2026.

Un token dava accesso ai repository di prodotto, distribuzione e sviluppo

L’ambito del token non si limitava a scaricare una dipendenza privata. Strix afferma che GitHub ha restituito lo scope OAuth repo e associato l’account all’organizzazione basetenlabs.

Le verifiche dei permessi in sola lettura hanno mostrato privilegi di amministratore e di push sul principale repository del prodotto di Baseten, sul repository GitOps usato per gestire i suoi cluster e sul tap Homebrew utilizzato per distribuire i suoi strumenti da riga di comando. Strix ha inoltre rilevato accesso in lettura e scrittura a diversi repository privati, compresi quelli associati a clienti.

Questa combinazione comportava diversi rischi distinti. Chiunque avesse avuto il token avrebbe potuto potenzialmente modificare il codice sorgente del prodotto, cambiare lo stato desiderato dell’infrastruttura gestita tramite GitOps o manomettere il canale usato per distribuire gli strumenti di sviluppo di Baseten. Strix afferma di non aver clonato il repository del cliente, inviato codice né modificato la configurazione dopo aver verificato i permessi.

Baseten ha limitato l’accesso al registro e ruotato il token

La cronologia della divulgazione di Strix colloca la segnalazione iniziale alle 11:10 di sera del 13 luglio 2026. La mattina seguente Baseten ha reso privato il progetto Harbor, ma Strix ha comunicato all’azienda che il token GitHub funzionava ancora.

Alle 4:34 del pomeriggio del 14 luglio, una persona identificata da Strix come Anton, del team di sicurezza di Baseten, ha confermato che il problema era critico, ha detto che il progetto era stato reso privato e ha confermato che il token era stato ruotato. Baseten ha anche chiesto a Strix di eliminare in modo sicuro le immagini scaricate. Strix ha confermato l’eliminazione alle 5:05 del pomeriggio e ha inviato due segnalazioni di gravità inferiore emerse dalla stessa scansione. L’azienda afferma che Baseten ha chiuso le due segnalazioni rimanenti il 17 luglio.

A settembre Strix ha informato Baseten che intendeva pubblicare la segnalazione e ha inviato all’azienda una bozza. La divulgazione descrive il team di sicurezza di Baseten come sollecito e afferma che l’azienda ha inviato magliette e felpe per ringraziare della segnalazione.

Perché è ancora necessario esaminare la cronologia delle vecchie immagini

Il problema tecnico è nato da una pratica di build comune: un token GitHub era stato passato come argomento di build di Docker, così che un passaggio potesse recuperare dipendenze private. Strix afferma che il comando aveva anche configurato Git con un URL autenticato, creando un secondo modo in cui la credenziale poteva persistere nell’immagine.

L’alternativa raccomandata da Docker è un mount di segreti BuildKit, che rende disponibile un token solo per la durata di un’istruzione di build. I team devono comunque verificare che i comandi che usano il segreto non lo scrivano in un file, nella configurazione di Git, in un livello dell’immagine o in una voce della cronologia di build.

Strix raccomanda di controllare l’accesso anonimo ai vecchi progetti e tag del registro, ispezionare le immagini con docker history --no-trunc, esaminare i blob di configurazione e i livelli e verificare a quali risorse possono accedere effettivamente le credenziali di build. Raccomanda inoltre di limitare i token al set minimo di permessi necessario e di assegnare loro una data di scadenza.

La segnalazione non è emersa da una ricerca mirata delle credenziali GitHub di Baseten. Strix afferma che il suo agente ha scoperto un registro trascurato, verificato che fosse possibile scaricare immagini in modo anonimo, scartato una credenziale non più valida, seguito la cronologia di build dell’immagine fino a un’altra credenziale e controllato autonomamente i permessi del secondo token sui repository. Il progetto Harbor e il token GitHub esposti sono stati disattivati prima che Strix pubblicasse il resoconto il 1 settembre 2026.