The Pulse

L’agente di IA di Strix ha trovato il token amministratore GitHub di Baseten in 25 minuti, secondo Strix

L’agente di sicurezza autonomo di Strix ha trovato un token di accesso personale GitHub di Baseten ancora attivo all’interno di un’immagine Docker scaricabile pubblicamente, secondo Strix. Il token consentiva l’accesso come amministratore e

AI.info Team · Scritto con l’IA · verificato · 2026-09-16

L’agente di sicurezza autonomo di Strix ha impiegato circa 25 minuti, secondo l’azienda, per trovare un token di accesso personale GitHub attivo e dotato di privilegi di amministratore all’interno di un’immagine Docker di Baseten scaricabile pubblicamente. Il team di sicurezza di Baseten ha poi classificato il problema come critico, ha limitato l’accesso al progetto del registry esposto e ha sostituito il token entro il pomeriggio successivo, secondo la segnalazione di Strix pubblicata il 1° settembre.

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

Un progetto Harbor pubblico esponeva più dei metadati delle immagini

La scansione è iniziata con una ricognizione dell’infrastruttura di Baseten esposta su internet. Strix ha trovato un registry di container Harbor all’indirizzo gcp-us-east4-zlw.registry.baseten.co, dove un progetto era configurato come pubblico, secondo la sua segnalazione.

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

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

La credenziale attiva si trovava nella cronologia di build di Docker

Strix ha trovato una seconda credenziale eseguendo TruffleHog ed esaminando 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 layer 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 rimanere nell’immagine finale, e raccomanda invece l’uso di mount temporanei per segreti o SSH.

Strix ha testato la credenziale con una richiesta GitHub GET /user in sola lettura. GitHub ha restituito una risposta positiva, identificando l’account come basetenbot. Il passaggio di build dell’immagine che ha esposto il token risaliva al 3 marzo 2023, secondo Strix, mentre la credenziale era ancora attiva quando l’azienda l’ha trovata nel luglio 2026.

Un solo token dava accesso ai repository di prodotto, deployment e sviluppo

L’ambito di accesso del token non si limitava al download di una dipendenza privata. GitHub ha restituito lo scope OAuth repo e ha associato l’account all’organizzazione basetenlabs, secondo Strix.

Le verifiche dei permessi in sola lettura hanno mostrato accesso come amministratore e permessi di push al repository principale del prodotto Baseten, al repository GitOps usato per gestire i suoi cluster e al tap Homebrew usato per distribuire i suoi strumenti da riga di comando. Strix ha anche trovato accesso in lettura e scrittura a diversi repository privati, tra cui repository associati a clienti.

Questa combinazione creava diversi rischi distinti. Chi fosse entrato in possesso del token avrebbe potuto alterare il codice sorgente del prodotto, modificare lo stato desiderato dell’infrastruttura gestita tramite GitOps o manomettere il canale usato per distribuire gli strumenti per sviluppatori di Baseten. Strix afferma di non aver clonato il repository del cliente, effettuato push di codice o modificato la configurazione dopo aver verificato i permessi.

Baseten ha limitato l’accesso al registry e sostituito il token

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

Alle 16:34 del 14 luglio, una persona identificata da Strix come Anton di Baseten Security ha confermato che il problema era critico, ha dichiarato che il progetto era stato reso privato e ha confermato che il token era stato sostituito. Baseten ha anche chiesto a Strix di eliminare in modo sicuro le immagini scaricate. Strix ha confermato l’eliminazione alle 17:05 e ha inviato due segnalazioni di minore gravità emerse dalla stessa scansione. Baseten ha chiuso quelle segnalazioni rimanenti il 17 luglio, secondo l’azienda.

A settembre Strix ha comunicato a Baseten l’intenzione di pubblicare la scoperta e ha inviato all’azienda una bozza. La segnalazione descrive il team di sicurezza di Baseten come pronto a rispondere e afferma che l’azienda ha inviato magliette e felpe per ringraziare della segnalazione del problema.

Perché è ancora necessario esaminare la cronologia delle vecchie immagini

Il problema tecnico è iniziato con una prassi di build comune: un token GitHub è stato passato come argomento di build di Docker affinché un passaggio della build potesse recuperare dipendenze private. Il comando configurava anche Git con un URL autenticato, creando una seconda possibilità che la credenziale rimanesse nell’immagine, secondo Strix.

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

Strix raccomanda di verificare l’accesso anonimo a vecchi progetti e tag del registry, esaminare le immagini con docker history --no-trunc, controllare i blob di configurazione e i layer e verificare a cosa possano effettivamente accedere le credenziali di build. Raccomanda inoltre di limitare i token al minimo insieme di permessi necessario e di assegnare loro una data di scadenza.

La scoperta non è nata da una ricerca mirata delle credenziali GitHub di Baseten. L’agente di Strix ha individuato un registry passato inosservato, verificato che il download anonimo delle immagini funzionasse, 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, secondo l’azienda. L’accesso al progetto Harbor esposto e quello tramite il token GitHub sono stati chiusi prima che Strix pubblicasse il resoconto il 1° settembre 2026.