Grafana Labs, breach su GitHub: codebase rubato e riscatto rifiutato
Grafana Labs conferma un'intrusione nel proprio ambiente GitHub tramite vulnerabilità Pwn Request. Codice sorgente esfiltrato, ma l'azienda rifiuta l'estorsion…
Contenuto
Grafana Labs ha reso pubblico il 16 maggio 2026 un breach del proprio ambiente GitHub, originato da una GitHub Action abilitata di recente e configurata con l'evento pull_request_target. Un attaccante ha sfruttato la cosiddetta vulnerabilità Pwn Request per estrarre token privilegiati, accedere a repository privati e tentare un'estorsione poi rifiutata. L'incidente mette al centro della discussione la fragilità della supply chain CI/CD anche per chi vende strumenti di observability.
La notifica ufficiale è arrivata tramite i canali di comunicazione dell'azienda, confermando che l'intrusione è stata rilevata grazie a sistemi di monitoraggio interni. Nonostante il tentativo di ricatto, Grafana ha scelto la trasparenza, pubblicando i dettagli tecnici dell'accaduto per allertare la comunità globale degli sviluppatori. L'evento sottolinea come anche configurazioni apparentemente standard possano nascondere insidie fatali se non gestite con criteri di isolamento rigorosi.
- La root cause è una GitHub Action abilitata nelle scorse settimane che usava l'evento pull_request_target, esponendo secrets durante le CI run.
- L'attaccante ha forkato un repository, iniettato istruzioni malevole tramite un comando curl e scaricato le environment variables per rubare i token.
- L'intrusione è stata scoperta solo quando uno dei migliaia di canary token distribuiti da Grafana si è attivato improvvisamente.
- L'attaccante ha replicato l'operazione contro almeno 4 repository privati aggiuntivi prima di tentare l'estorsione monetaria.
- Grafana ha rifiutato il pagamento, confermando che nessun dato cliente o informazione personale è stata compromessa durante l'incidente.
Come è entrato l'attaccante: la Pwn Request su pull_request_target
Il punto di ingresso è stato una GitHub Action attivata nelle scorse settimane su un repository pubblico. Il workflow era triggerato dall'evento pull_request_target, una modalità che esegue il codice nel contesto del repository di destinazione concedendo ampie autorizzazioni, incluso l'accesso ai secrets. Questa configurazione, nota in letteratura come Pwn Request, consente a chiunque apra una pull request da un fork di eseguire codice con privilegi elevati.
Secondo la ricostruzione diffusa dalla società, l'attaccante ha forkato il repository bersaglio, ha iniettato istruzioni malevole attraverso un comando curl e ha scaricato le environment variables in un file cifrato con una chiave privata. In questo modo ha potuto estrarre i secrets conservati nell'ambiente CI/CD e ottenere un token GitHub con privilegi estesi, aprendosi la strada verso i repository interni non pubblici.
La vulnerabilità Pwn Request non è una novità nel panorama delle minacce alla supply chain: consente a un attaccante di modificare il codice in un fork e di farlo eseguire nel contesto del repository originale attraverso una pull request apparentemente innocua. Le variabili d'ambiente, che spesso contengono chiavi API, token di accesso e credenziali cloud, diventano così leggibili dall'ambiente CI/CD, trasformando una semplice pull request in una backdoor di alto profilo per l'esfiltrazione.
È necessario chiarire un'imprecisione lessicale emersa in alcune prime analisi giornalistiche: sebbene alcune fonti abbiano fatto riferimento al furto di un "database", l'evidenza tecnica e le dichiarazioni di Grafana indicano che l'oggetto dell'esfiltrazione è stato esclusivamente il codebase (codice sorgente) contenuto nei repository compromessi. Non vi è alcuna prova tecnica che database di produzione contenenti dati sensibili degli utenti siano stati raggiunti o scaricati.
Dalla compromissione del token all'esfiltrazione di altri quattro repository
Con il token compromesso, l'attaccante non si è fermato al repository iniziale. Dopo aver cancellato il fork usato per il primo accesso, ha replicato la stessa catena di attacco contro almeno 4 repository privati aggiuntivi, scaricando porzioni del codebase interno. Grafana non ha quantificato il volume esatto del materiale esfiltrato, limitandosi a confermare che si tratta di codice proprietario sottratto attraverso i privilegi dei token rubati.
La diffusione laterale all'interno dell'organizzazione è avvenuta senza che fossero necessarie nuove tecniche di intrusione: l'attaccante ha semplicemente riutilizzato il token GitHub compromesso per clonare repository aggiuntivi, sfruttando la fiducia implicita che il sistema CI/CD ripone nei secrets condivisi. Questo schema è particolarmente insidioso perché bypassa i controlli di accesso tradizionali, muovendosi all'interno di un perimetro che il sistema considera legittimo, protetto da credenziali valide.
Parallelamente è emersa la rivendicazione di un gruppo che si fa chiamare CoinbaseCartel, un nome che circola nei forum di cybercrime da circa settembre 2025. Secondo quanto riportato da analisti di terze parti, il gruppo avrebbe colpito quasi 170 vittime in vari settori industriali. Tuttavia, è fondamentale mantenere la massima cautela: Grafana Labs non ha confermato alcuna attribuzione ufficiale e i dati sulla storia del gruppo non sono verificati indipendentemente.
L'uso di nomi altisonanti e la rivendicazione di centinaia di attacchi sono tattiche comuni nelle operazioni di estorsione per aumentare la pressione psicologica sulla vittima. Nel caso di Grafana, la rivendicazione di CoinbaseCartel rimane una possibilità non validata. L'azienda ha preferito concentrarsi sull'analisi forense e sulla chiusura delle falle tecniche piuttosto che alimentare la narrativa mediatica dei presunti aggressori, seguendo i protocolli standard di gestione incidenti.
Il canary token che ha svegliato Grafana
La detection non è avvenuta attraverso i consueti allarmi sull'infrastruttura, ma grazie a uno dei migliaia di canary token distribuiti da Grafana all'interno del perimetro. Quando l'attaccante ha mosso i primi passi nel repository compromesso e ha tentato di utilizzare una credenziale civetta, il token ha generato un alert istantaneo, dando il via all'indagine interna. È un dettaglio che evidenzia il valore tattico dei tripwire digitali.
L'uso dei canary token come primo allarme ha evidenziato sia il merito della pratica difensiva, sia il suo limite intrinseco: il trigger è scattato quando l'attaccante aveva già ottenuto accesso iniziale e stava iniziando l'esplorazione. Grafana non ha reso noti i dettagli tecnici del token specifico, ma la dinamica conferma che i tripwire sono essenziali per contenere i tempi di permanenza (dwell time), pur non potendo bloccare l'ingresso iniziale.
Grafana ha spiegato di avere invalidato immediatamente tutte le credenziali compromesse non appena ricevuto l'alert. Contestualmente, il team di sicurezza ha rimosso la GitHub Action vulnerabile e ha disabilitato tutti i workflow sui repository pubblici come misura precauzionale. Non è stata fornita una timeline precisa sulla durata esatta dell'intrusione prima della scoperta, ma l'attivazione del canary token ha impedito una persistenza più lunga e dannosa.
Extortion rifiutata e la linea di remediation
Dopo avere ottenuto il codebase, l'attaccante ha contattato Grafana Labs per chiedere un pagamento in cambio della non pubblicazione del codice rubato. La società ha rifiutato categoricamente il ricatto. Per giustificare la scelta, l'azienda ha citato una nota posizione dell'FBI, mediata dalle ricostruzioni tecniche dell'incidente, secondo cui «paying a ransom doesn’t guarantee you or your organization will get any data back».
"Our investigation has determined that no customer data or personal information was accessed during this incident, and we have found no evidence of impact to customer systems or operations" — Grafana Labs, post ufficiale su X
Nella comunicazione ufficiale pubblicata sul proprio blog e su X, Grafana ha assicurato che l'indagine non ha rilevato accessi a dati cliente. Il rifiuto del riscatto e la pubblicazione immediata dei fatti segnano una scelta netta in un settore spesso tentato dall'omertà. Grafana ha fornito la root cause e le contromisure adottate, offrendo alla comunità un caso studio concreto sui rischi delle configurazioni CI/CD errate e sulla sicurezza della supply chain.
Il rifiuto di pagare non è solo una questione etica, ma anche una strategia di difesa a lungo termine. Cedendo alle richieste, le aziende finiscono per finanziare ulteriori attacchi e diventano bersagli privilegiati per future estorsioni. Grafana ha scelto di investire risorse nella remediation tecnica e nella trasparenza verso i propri utenti, consolidando la fiducia nonostante la vulnerabilità emersa nel proprio workflow di sviluppo.
Cosa fare adesso
Audit immediato delle GitHub Actions che usano pull_request_target: è fondamentale rimuovere questo evento dove non strettamente necessario. Bisogna limitare i secrets esclusivamente ai workflow che ne hanno un bisogno operativo documentato. Sostituire pull_request_target con l'evento pull_request standard sui repository pubblici che accettano contributi esterni elimina alla radice la superficie d'attacco sfruttata in questo incidente specifico.
Verifica mirata dei workflow e dei fork recenti: si raccomanda di controllare i log di esecuzione per ogni GitHub Action abilitata di recente, con particolare attenzione ai workflow attivati da fork esterni. Una verifica dei fork creati negli ultimi mesi può rivelare tentativi di iniezione di codice simili a quelli subiti da Grafana, permettendo di identificare eventuali tentativi di esfiltrazione di variabili d'ambiente non ancora rilevati.
Implementare canary token o honeytoken nei repository: inserire credenziali di esca (come finte chiavi AWS o token API inattivi) nelle environment variables permette di ricevere allarmi tempestivi. Questa pratica riduce drasticamente il time-to-detection. Se un attaccante abusa di un token CI/CD e tenta di usare queste esche, il team di sicurezza viene allertato immediatamente, limitando i danni potenziali di una compromissione già avvenuta.
Applicazione del principio del least privilege ai token CI/CD: è necessario ridurre la durata, lo scope e i permessi dei secrets memorizzati in GitHub. Valutare l'uso di ambienti di esecuzione isolati e privi di accesso alla rete esterna per le CI run che derivano da contributi esterni. Rivedere periodicamente le autorizzazioni concesse ai workflow automatici garantisce che un singolo errore di configurazione non esponga l'intero patrimonio informativo aziendale.
L'episodio rappresenta un paradosso significativo: una realtà che costruisce la propria reputazione sull'observability è stata colpita dalla catena di una singola misconfiguration. La lezione non riguarda solo Grafana, ma chiunque gestisca codebase pubblici. La detection ha funzionato grazie ai canary token, ma a intrusione già avvenuta: la vera sfida per il futuro è la prevenzione delle Pwn Request prima che il codice malevolo venga eseguito.
Domande frequenti
Il gruppo CoinbaseCartel è davvero responsabile dell'attacco?
La responsabilità non è confermata ufficialmente. Sebbene il gruppo abbia rivendicato l'azione citando l'accesso ai dati di Grafana, l'azienda non ha validato tale attribuzione. Le informazioni su CoinbaseCartel, incluse le presunte 170 vittime e la data di fondazione nel 2025, provengono da rivendicazioni del gruppo stesso e non sono verificate indipendentemente.
Perché la configurazione pull_request_target è considerata così rischiosa?
Il rischio risiede nel fatto che pull_request_target esegue il workflow nel contesto del repository base, non del fork. Questo garantisce al codice della pull request l'accesso ai secrets e ai token del repository originale. Un attaccante può quindi iniettare script nel fork che, una volta triggerata la PR, leggono e inviano all'esterno le chiavi private dell'organizzazione.
I clienti Grafana devono cambiare le proprie password o API key?
Secondo le dichiarazioni ufficiali di Grafana Labs, non è necessaria alcuna azione da parte degli utenti. L'indagine interna ha escluso accessi ai dati dei clienti, alle informazioni personali o ai sistemi di produzione. L'impatto è stato limitato al codice sorgente di alcuni repository GitHub. Si consiglia comunque di seguire i canali ufficiali per eventuali aggiornamenti sulla sicurezza dei prodotti.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.