GitHub Actions, compromessa tj-actions/changed-files: segreti esposti nei log di migliaia di repository

Un attaccante ha spostato tutti i tag di una GitHub Action usata da oltre 23.000 repository verso un commit malevolo che stampava i segreti delle pipeline nei log. Come capire se sei coinvolto.

GitHub Actions, compromessa tj-actions/changed-files: segreti esposti nei log di migliaia di repository

Il 14 marzo i ricercatori di StepSecurity, società specializzata nella sicurezza delle pipeline, hanno notato un comportamento anomalo in tj-actions/changed-files, una GitHub Action molto diffusa che oltre 23.000 repository usano per individuare i file modificati in un commit. Qualcuno l’aveva trasformata in uno strumento per rubare segreti.

L’attaccante ha ottenuto un token di accesso personale dell’account bot che gestisce il progetto. Con quel token ha creato un commit malevolo e ha spostato tutti i tag di versione, dalla v1 alla v45.0.7, perché puntassero lì. Ogni workflow che usava l’action tramite un tag, anche fissato a una versione precisa, tra il 14 e il 15 marzo ha eseguito il codice dell’attaccante.

Quel codice leggeva la memoria del runner, estraeva i segreti della pipeline, come chiavi cloud, token npm e GitHub, password e chiavi private, e li stampava nei log del workflow, codificati due volte in base64. Nei repository pubblici quei log li può leggere chiunque. La falla è registrata come CVE-2025-30066, la versione corretta è la 46.0.1 e il token compromesso è stato revocato. Come l’attaccante abbia ottenuto quel token, e se l’obiettivo fosse un repository in particolare, non è ancora chiaro.

Il tag che si sposta

Molti sviluppatori pensano che scrivere @v35 in un workflow significhi usare sempre la stessa versione. Non è così. I tag di Git sono etichette mobili, e chi ha accesso in scrittura al repository può spostarle dove vuole. L’unico riferimento immutabile è l’hash completo del commit. Questo attacco ha sfruttato proprio quella fiducia mal riposta, colpendo anche chi pensava di aver fatto le cose per bene.

Cerca nei tuoi repository i workflow che usano tj-actions/changed-files e apri i log delle esecuzioni del 14 e 15 marzo. Se nella sezione dell’action trovi lunghe stringhe in base64, considera esposti i segreti. Ruotali subito tutti, partendo dai repository pubblici, ed elimina i log interessati. Poi aggiorna alla 46.0.1, oppure sostituisci l’action con un’alternativa o con comandi Git diretti.

Per il futuro, fissa tutte le action di terze parti all’hash del commit, limita le connessioni in uscita dei runner e dai al token dei workflow solo i permessi minimi. Sono tre righe di configurazione. Ripulire una pipeline compromessa richiede giorni.

Condividi LinkedIn X Telegram

Continua a leggere