Una scansione di 3,5 milioni di host pubblici ha riportato a galla un problema che gli sviluppatori considerano risolto da anni: le directory .git lasciate accessibili sui server di produzione. Il 20 agosto 2026 la società di sicurezza britannica Intruder ha pubblicato una ricerca firmata dal proprio team guidato da Tom Steer che ha trovato 28.000 repository esposti, 400 chiavi AWS attive e 107 chiavi segrete Stripe recuperabili con un semplice scanner automatico. Non un test di laboratorio, ma dati reali di aziende che oggi, mentre leggi questo articolo, potrebbero non sapere ancora di essere state esposte.
Il caso interessa da vicino anche le aziende italiane ed europee, perché il problema non riguarda un fornitore specifico o una piattaforma cloud in particolare. Riguarda una pratica di configurazione dei server web che continua a ripetersi, nonostante sia documentata da almeno un decennio nelle guide di hardening. Vediamo cosa è successo, quali dati sono stati esposti e cosa cambia per chi gestisce infrastrutture cloud e pipeline di sviluppo.
Cosa ha scoperto Intruder nella scansione di 3,5 milioni di host
Il team di ricerca di Intruder ha usato uno strumento interno, ribattezzato gitreaper, per scandagliare 3,5 milioni di host attivi su internet alla ricerca di directory .git raggiungibili via HTTP. Il risultato: 28.000 repository accessibili senza alcuna autenticazione. Da questi archivi, i ricercatori hanno estratto 400 chiavi di accesso AWS ancora funzionanti, 107 chiavi API Stripe, 123 chiavi API OpenAI, 80 token per bot Telegram e 17 token di accesso personale GitHub (PAT). Gli stessi numeri sono stati ripresi e confermati anche da GBHackers, che ha seguito la pubblicazione della ricerca originale.
La causa tecnica è quasi sempre la stessa: un server web (Apache, Nginx o simili) configurato per servire i file statici di un progetto senza escludere la cartella .git che Git crea automaticamente in ogni repository locale. Quando quella cartella finisce dentro la directory pubblica del sito, chiunque può scaricarla con strumenti gratuiti come git-dumper e ricostruire l’intero repository, cronologia dei commit compresa.
Alcune delle chiavi individuate da Intruder erano ancora valide al momento del test, un dettaglio che i ricercatori descrivono come il segnale più preoccupante dell’intera indagine. Non si tratta di credenziali vecchie e revocate da tempo, ma di accessi che un aggressore avrebbe potuto sfruttare nello stesso momento della scoperta.
Come restano esposte le directory .git sui server di produzione
Il meccanismo alla base del problema è banale da spiegare ma difficile da eliminare del tutto su larga scala. Quando uno sviluppatore esegue git init in una cartella di progetto, Git crea una sottocartella nascosta con l’intera cronologia del codice: ogni commit, ogni branch, ogni file modificato e, spesso, ogni segreto che qualcuno ha incollato per errore in un file di configurazione prima di accorgersene e rimuoverlo.
Se quella cartella di progetto coincide con la root pubblica del sito, o viene copiata lì per errore durante un deploy manuale, la directory .git diventa raggiungibile da chiunque conosca l’indirizzo. Gli scanner automatici come quello usato da Intruder non hanno bisogno di indovinare nulla: interrogano l’URL /.git/HEAD su milioni di domini in sequenza e, se ottengono una risposta valida, scaricano l’intero pacchetto di oggetti Git.
Il punto critico, spiegato nella ricerca, è che cancellare un segreto da un file e fare un nuovo commit non lo elimina dalla cronologia. Il dato resta comunque negli oggetti Git precedenti, recuperabile con un comando git log -p o simili una volta che l’attaccante ha ricostruito il repository in locale. È lo stesso principio alla base di molte fughe di credenziali documentate negli ultimi anni su GitHub pubblico, solo applicato qui a server aziendali che nessuno pensava di dover controllare.
I numeri del leak: repository, chiavi e token contati uno per uno
La tabella seguente riassume i dati pubblicati da Intruder il 20 agosto 2026, con il tipo di credenziale, la quantità individuata e il livello di rischio associato secondo la classificazione dei ricercatori.
| Tipo di credenziale | Quantità trovata | Rischio principale | Stato al momento del test |
|---|---|---|---|
| Chiavi di accesso AWS | 400 | Accesso diretto a bucket S3, EC2, database cloud | Alcune ancora attive |
| Chiavi API Stripe | 107 | Accesso a dati di pagamento e transazioni | Alcune ancora attive |
| Chiavi API OpenAI | 123 | Uso non autorizzato di servizi IA, costi a carico della vittima | Alcune ancora attive |
| Token bot Telegram | 80 | Controllo di bot e accesso a chat private | Alcune ancora attive |
| Token GitHub personali (PAT) | 17 | Accesso a codice sorgente privato e altri segreti | Alcune ancora attive |
| Repository .git esposti totali | 28.000 | Cronologia completa del codice recuperabile | Pubblicamente accessibili |
Un dato che colpisce è la varietà dei servizi coinvolti. Non parliamo solo di infrastruttura cloud, ma di pagamenti, intelligenza artificiale e messaggistica, tre ambiti che oggi gestiscono dati sensibili e flussi economici reali. Una singola chiave Stripe compromessa può bastare per interrogare transazioni e dati parziali delle carte, mentre una chiave OpenAI attiva può generare costi di consumo a carico dell’azienda vittima, anche senza toccare direttamente altri sistemi.
Chiavi AWS: la porta d’accesso diretta al cloud aziendale
Le 400 chiavi AWS individuate rappresentano il rischio più concreto dell’intera ricerca. Una chiave di accesso valida può aprire, a seconda dei permessi assegnati, bucket S3, istanze EC2, database RDS o intere configurazioni di rete. Intruder documenta un caso in cui una chiave esposta dava accesso a un bucket contenente fascicoli del personale, con registri di presenza e documenti disciplinari dei dipendenti di un’organizzazione.
In un secondo caso citato dai ricercatori, una chiave collegata a un servizio di pagamento ha permesso di consultare cronologie di transazioni, dati di fatturato e dettagli bancari parziali. Sono esattamente gli scenari che i team di sicurezza informatica temono di più: non un attacco tecnico sofisticato, ma un accesso diretto reso possibile da una configurazione lasciata aperta per mesi o anni senza che nessuno se ne accorgesse.
Il problema si aggrava quando le chiavi hanno permessi troppo ampi, una pratica comune quando un team crea credenziali IAM “temporanee” per un test e poi dimentica di restringerne i privilegi o di ruotarle. Una chiave con permessi amministrativi, unita a un accesso pubblico non protetto, trasforma un errore di configurazione minore in una violazione su scala aziendale.
Stripe e OpenAI: pagamenti e servizi IA nel mirino
Le 107 chiavi Stripe trovate nella ricerca aggiungono un tassello a un quadro già preoccupante sul fronte dei pagamenti online. Un’indagine separata, pubblicata da Security Affairs nel 2026, ha documentato oltre 50.000 chiavi segrete Stripe esposte in repository pubblici, log di GitHub Actions e server mal configurati, un numero che mostra come il problema non sia isolato al solo caso Intruder ma rifletta un’abitudine diffusa tra gli sviluppatori di incollare chiavi direttamente nel codice invece di usare variabili d’ambiente o gestori di segreti dedicati.
Le 123 chiavi OpenAI portano un rischio diverso ma altrettanto concreto per le aziende: consumo non autorizzato a pagamento. Chi ruba una chiave API attiva può generare migliaia di richieste verso i modelli linguistici, con fatture che arrivano all’organizzazione proprietaria settimane dopo, quando il danno economico è già fatto. Nel 2026, con la diffusione di applicazioni basate su modelli di linguaggio in quasi ogni settore, questo tipo di abuso sta diventando una voce di rischio che i team finance iniziano a monitorare al pari delle frodi con carta di credito.
Telegram e GitHub: token minori, danni non trascurabili
Gli 80 token per bot Telegram individuati sembrano, a prima vista, il dato meno grave dell’elenco. In realtà un token Telegram compromesso permette di impersonare il bot, leggere messaggi nei canali a cui è collegato e inviare comunicazioni a nome dell’organizzazione, un vettore usato spesso per campagne di phishing rivolte proprio contro i clienti dell’azienda colpita.
I 17 token di accesso personale GitHub sono invece, numericamente, i meno diffusi ma tra i più pericolosi in termini di superficie d’attacco. Un PAT valido può dare accesso a repository privati, pipeline di CI/CD e, in alcuni casi, ad altri segreti memorizzati come variabili nei sistemi di build. È lo stesso tipo di credenziale al centro di diversi incidenti nella catena di fornitura del software osservati negli ultimi due anni, dove un singolo token rubato ha permesso di risalire a decine di altri sistemi collegati.
Il caso dei fascicoli dei dipendenti e dei dati bancari
Oltre alle credenziali tecniche, Intruder segnala che diversi repository contenevano documenti interni non pensati per la pubblicazione: contratti, fogli di calcolo con dati di fatturato, registri di presenza e fascicoli disciplinari dei dipendenti. Materiale che finisce spesso nei repository per comodità, magari come parte di script di test o esportazioni temporanee, e che nessuno rimuove prima del deploy in produzione.
Questo aspetto sposta il problema oltre la pura sicurezza informatica e lo porta dentro il perimetro della protezione dei dati personali. Un fascicolo disciplinare o un registro di presenza contiene dati che, sotto il GDPR, richiedono basi giuridiche specifiche per il trattamento e per la conservazione. La loro esposizione pubblica, anche se accidentale, configura potenzialmente una violazione di dati personali soggetta a notifica.
Perché la cronologia Git nasconde segreti che si credevano cancellati
Uno degli aspetti più istruttivi della ricerca riguarda la persistenza dei dati nella cronologia Git. Molti sviluppatori credono che rimuovere una password da un file di configurazione e fare commit della modifica risolva il problema. Non è così: gli oggetti Git precedenti restano nel repository a meno che non vengano riscritti attivamente con strumenti come git filter-repo o BFG Repo-Cleaner, un’operazione che quasi nessun team esegue di routine.
Gli scanner automatici usati dagli aggressori, una volta scaricata la cartella .git, ricostruiscono l’intero storico e lo analizzano con pattern matching per individuare stringhe che somigliano a chiavi API, token o password. È un processo che richiede pochi secondi per repository di dimensioni contenute, il che spiega perché Intruder sia riuscito a coprire 3,5 milioni di host in tempi relativamente brevi con un solo strumento automatizzato.
Non è un caso isolato: il trend delle fughe di segreti dal 2024 a oggi
Il caso Intruder si inserisce in un trend documentato da più fonti indipendenti negli ultimi due anni. La società GitGuardian, nel suo report annuale sullo stato della dispersione dei segreti, ha rilevato 23,8 milioni di segreti esposti su repository pubblici GitHub nel solo 2024, in crescita del 25% rispetto all’anno precedente. Parallelamente, CSO Online ha riportato dati di GreyNoise su quattro picchi distinti di scansioni automatizzate rivolte a file di configurazione Git esposti, registrati tra settembre 2024 e aprile 2025: tre picchi con circa 3.000 indirizzi IP unici ciascuno e un quarto picco, ad aprile 2025, con quasi 4.800 indirizzi IP unici.
La tabella seguente mette a confronto le principali ricerche pubblicate sul tema negli ultimi due anni, per dare un’idea della scala e della continuità del problema.
| Fonte | Periodo | Dato principale | Ambito |
|---|---|---|---|
| GitGuardian (State of Secrets Sprawl) | 2024, dati pubblicati 2025 | 23,8 milioni di segreti esposti su GitHub pubblico | Repository pubblici, non solo .git |
| GreyNoise / CSO Online | Set. 2024 – Apr. 2025 | 4 picchi di scansione, da ~3.000 fino a quasi 4.800 IP unici per picco | File di configurazione Git esposti |
| Ricerca su chiavi Stripe (Security Affairs) | 2026 | Oltre 50.000 chiavi Stripe esposte | Codice pubblico, log CI/CD, server mal configurati |
| Intruder (gitreaper) | 20 agosto 2026 | 28.000 repository .git esposti su 3,5 milioni di host | Directory .git su server di produzione |
Il confronto mostra una progressione chiara: dalla dispersione generica di segreti nel codice pubblico, al monitoraggio degli attacchi automatizzati, fino alla misurazione diretta dell’esposizione delle directory Git su server aziendali. Ogni ricerca guarda un angolo diverso dello stesso problema, e i numeri, lungi dal calare, continuano a crescere di anno in anno. Lo stesso schema, credenziali riusate e rivendute su più fronti, era già emerso nella nostra analisi sui 16 miliardi di credenziali esposte, dove il denominatore comune era ancora una volta la scarsa igiene nella gestione delle password e delle chiavi di accesso.
L’impatto sul mercato: costi, assicurazioni e reputazione
Per le aziende coinvolte, il costo di un incidente di questo tipo va ben oltre la revoca delle chiavi compromesse. Le polizze di cyber assicurazione, sempre più diffuse tra le medie imprese europee, richiedono in fase di sottoscrizione una valutazione della postura di sicurezza che include esplicitamente il controllo su segreti esposti e configurazioni pubbliche. Un incidente documentato può far salire i premi al rinnovo o, in alcuni casi, portare all’esclusione di determinate coperture.
C’è poi il costo indiretto della fiducia. Un’azienda che scopre, tramite un ricercatore esterno o una segnalazione pubblica, che i propri segreti erano accessibili da mesi deve gestire comunicazioni verso clienti, partner e in alcuni casi investitori. Nel settore dei pagamenti, dove opera una parte delle chiavi Stripe individuate, la reputazione è un asset che si ricostruisce in anni, non in settimane.
Il costo del consumo non autorizzato
Va aggiunto un elemento spesso sottovalutato quando si parla di questo tipo di incidenti. Anche senza un furto di dati vero e proprio, un uso fraudolento prolungato di chiavi cloud attive genera fatture impreviste, in alcuni casi di importo rilevante, prima ancora che il team tecnico si accorga della violazione e revochi le credenziali.
Cosa rischia l’Italia e le aziende europee
Il problema non ha confini geografici: qualsiasi server raggiungibile da internet può finire nella scansione di uno strumento come gitreaper, indipendentemente dal paese in cui è ospitato. Le aziende italiane che gestiscono ambienti di sviluppo interni con deploy manuali, o che si affidano a piccoli fornitori esterni per la gestione dei siti, sono tra le più esposte, perché spesso mancano di processi automatizzati di controllo pre-produzione.
Sul fronte normativo, un’eventuale esposizione di dati personali attraverso una directory Git dimenticata online rientra a pieno titolo negli obblighi di notifica previsti dal GDPR, con tempistiche di 72 ore verso il Garante Privacy in caso di rischio per i diritti degli interessati. Le stesse aziende soggette alla direttiva NIS2, ormai in vigore anche per numerosi settori italiani, devono considerare questo tipo di esposizione come un possibile incidente da segnalare, soprattutto quando coinvolge infrastrutture critiche o fornitori di servizi essenziali.
Come proteggersi: checklist tecnica per sviluppatori e team DevOps
La buona notizia è che la protezione contro questo specifico problema è relativamente semplice da implementare, e non richiede investimenti importanti. Un controllo periodico della propria superficie esposta, simile a quello descritto nella nostra guida sulla sicurezza cloud con Prowler e Trivy, individua questo tipo di errore prima che lo trovi un aggressore.
Bloccare l’accesso alla cartella .git a livello di server
Il primo passo è bloccare l’accesso pubblico alla cartella .git a livello di server web. Su Nginx basta una regola come questa:
location ~ /\.git {
deny all;
return 404;
}Su Apache, l’equivalente si ottiene con un blocco simile nel file .htaccess o nella configurazione del virtual host:
RedirectMatch 404 /\.git
<DirectoryMatch "^/.*/\.git/">
Require all denied
</DirectoryMatch>Oltre alla configurazione del server, servono alcune pratiche organizzative.
Buone pratiche per ridurre il rischio nel tempo
Ecco i punti principali che ogni team dovrebbe verificare:
- Non copiare mai l’intera cartella di progetto in produzione: usare pipeline di build che escludono esplicitamente la cartella .git
- Ruotare periodicamente le chiavi AWS, Stripe e OpenAI, anche in assenza di segnali di compromissione
- Adottare un gestore di segreti dedicato (come AWS Secrets Manager o HashiCorp Vault) invece di variabili incollate nel codice
- Eseguire scansioni periodiche dei propri domini con strumenti come gitleaks o TruffleHog prima del deploy
- Riscrivere la cronologia Git con git filter-repo quando un segreto è stato committato per errore, non limitarsi a un nuovo commit
- Impostare permessi IAM minimi per ogni chiave, evitando credenziali con accesso amministrativo per compiti di test
Chi vuole verificare rapidamente se un proprio dominio espone la cartella .git può semplicemente provare a visitare l’indirizzo https://tuodominio.it/.git/HEAD: se il server restituisce un contenuto testuale invece di un errore 404, la configurazione va corretta immediatamente.
Il collegamento con l’OWASP Top 10 e la gestione dei segreti
L’esposizione di directory .git e la gestione scorretta dei segreti si collegano direttamente a due categorie della OWASP Top 10, approfondita anche nella nostra guida pratica in Node.js: le configurazioni di sicurezza errate e l’esposizione di dati sensibili. Non è un caso che i due problemi vengano spesso citati insieme nelle guide di hardening: una directory pubblica mal configurata è la porta d’ingresso, un segreto incollato nel codice è il premio che l’aggressore trova dall’altra parte.
Molti dei problemi documentati da Intruder si sarebbero potuti evitare anche con controlli più semplici a livello di API, come il rate limiting sulle chiamate che usano le chiavi compromesse: un volume anomalo di richieste da un indirizzo IP sconosciuto è spesso il primo segnale di un uso fraudolento di credenziali rubate, e un sistema di allarme ben configurato può limitare il danno anche quando la chiave è già stata sottratta.
Obblighi GDPR e notifica delle violazioni
Quando un’esposizione come questa coinvolge dati personali, come nel caso dei fascicoli dei dipendenti citati da Intruder, scattano gli obblighi previsti dagli articoli 33 e 34 del GDPR: notifica all’autorità di controllo entro 72 ore dalla scoperta e, nei casi di rischio elevato, comunicazione diretta agli interessati. Le sanzioni per mancata notifica possono aggiungersi a quelle per la violazione stessa, aumentando in modo significativo l’esposizione finanziaria dell’azienda coinvolta.
Va ricordato che un’esposizione di questo tipo è spesso più difficile da giustificare davanti a un’autorità di controllo rispetto a un attacco mirato e sofisticato, perché deriva da una configurazione di base non verificata, non da una vulnerabilità zero-day sconosciuta al momento dell’incidente.
Previsioni per i prossimi mesi
Sulla base dei dati raccolti e del trend osservato negli ultimi due anni, ecco alcuni scenari plausibili per la seconda metà del 2026 e l’inizio del 2027.
- Altri fornitori di scanner di sicurezza pubblicheranno ricerche simili, probabilmente con numeri di repository esposti ancora più alti, dato che la superficie di internet continua a crescere
- I fornitori cloud (AWS, Google Cloud, Microsoft Azure) rafforzeranno i controlli automatici che rilevano chiavi esposte pubblicamente e le disattivano in tempo quasi reale, come già fanno in parte oggi
- Le richieste di assicurazione cyber includeranno sempre più spesso una verifica esplicita sull’assenza di directory di controllo versione esposte, come requisito per la sottoscrizione della polizza
- Cresceranno le segnalazioni di consumo non autorizzato legate a chiavi API per servizi di intelligenza artificiale, con conseguente pressione sui fornitori affinché offrano limiti di spesa configurabili di default
- Le autorità di controllo europee, incluso il Garante Privacy italiano, tratteranno con maggiore severità le violazioni derivanti da configurazioni di base trascurate, considerandole prova di carenze strutturali nella gestione della sicurezza
Nessuna di queste previsioni richiede innovazioni tecnologiche particolari. Gli strumenti per prevenire l’intero problema esistono da anni: la vera sfida resta l’applicazione costante di pratiche di base su larga scala, in un panorama di sviluppo software dove la velocità di rilascio spesso conta più del controllo sistematico delle configurazioni.
Domande frequenti
Cosa significa avere una directory .git esposta pubblicamente?
Significa che chiunque può scaricare l’intera cronologia di un repository Git direttamente dal server web, senza credenziali, semplicemente conoscendo l’indirizzo del sito. Da lì è possibile ricostruire il codice sorgente completo e tutti i segreti mai committati, anche quelli rimossi in versioni successive.
Come faccio a sapere se il mio sito espone la cartella .git?
Prova a visitare l’indirizzo del tuo dominio seguito da /.git/HEAD. Se il server restituisce un errore 404, la cartella è protetta. Se invece mostra del testo, la configurazione va corretta subito bloccando l’accesso a livello di server web.
Basta cancellare un file con un segreto e fare un nuovo commit per risolvere il problema?
No. Il segreto resta negli oggetti della cronologia Git precedente. Serve riscrivere la cronologia con strumenti come git filter-repo o BFG Repo-Cleaner, oltre a revocare e sostituire la chiave compromessa.
Quali servizi cloud sono più a rischio in casi come questo?
Nella ricerca di Intruder, i servizi più colpiti sono stati AWS (400 chiavi), Stripe (107 chiavi) e OpenAI (123 chiavi), oltre a Telegram e GitHub. In generale qualsiasi servizio che usa chiavi API statiche incollate nel codice è a rischio.
Un’esposizione di questo tipo va notificata al Garante Privacy?
Se tra i dati esposti ci sono informazioni personali, come nel caso dei fascicoli dei dipendenti citati nella ricerca, la notifica entro 72 ore prevista dal GDPR si applica. La valutazione va fatta caso per caso in base al tipo di dati coinvolti e al rischio per gli interessati.
Esistono strumenti gratuiti per controllare i propri repository prima del deploy?
Sì. Strumenti open source come gitleaks e TruffleHog permettono di scansionare un repository alla ricerca di chiavi e segreti prima che finiscano in produzione, e possono essere integrati direttamente nelle pipeline di CI/CD.
Quanto è diffuso questo problema rispetto ad altre fughe di segreti?
Il confronto con altre ricerche, come quella di GitGuardian sui 23,8 milioni di segreti esposti su GitHub pubblico nel 2024, mostra che l’esposizione di directory .git è una porzione specifica di un problema molto più ampio, quello della gestione scorretta dei segreti nello sviluppo software.
Cosa deve fare un’azienda che scopre di avere una directory .git esposta?
Bloccare immediatamente l’accesso pubblico a livello di server, revocare e ruotare tutte le chiavi presenti nel repository, riscrivere la cronologia Git se contiene segreti, e valutare con il proprio responsabile della protezione dei dati se scatta l’obbligo di notifica al Garante Privacy.
