Chiavi API Stripe esposte: a rischio i dati di 688.363 clienti

La pubblicazione del 18 agosto 2026 va interpretata soprattutto come un’esposizione di credenziali appartenenti ai merchant, non come una violazione confermata della piattaforma Stripe. Secondo i report, un archivio gratuito di circa 35 GB conteneva 17.654 file provenienti da 659 account commerciali e informazioni collegate a una stima di 688.363 clienti in 42 Paesi. Si tratta di stime riportate dalle fonti: alcune affermazioni più ampie dell’attore non sono state verificate in modo indipendente.

Che cosa conteneva l’archivio

I dati avrebbero riguardato il periodo compreso tra gennaio 2022 e giugno 2026. Tra le categorie indicate nei report figuravano:

• oggetti cliente Stripe e informazioni di contatto;
• addebiti, Payment Intent, sessioni Checkout, fatture, rimborsi e contestazioni;
• pagamenti ai merchant e transazioni del saldo;
• abbonamenti, prodotti e prezzi;
• metadati relativi ai pagamenti, tra cui circuito della carta, ultime quattro cifre, scadenza, tipologia di finanziamento, Paese di emissione e identificativo di pagamento.

Le analisi disponibili non indicano la presenza dei numeri completi delle carte. Questo riduce alcune forme di frode diretta sulle carte, ma non elimina il rischio derivante dall’esposizione di credenziali API e di informazioni dettagliate su clienti e transazioni.

I ricercatori hanno riferito di aver individuato 650 chiavi segrete live sk_live e nove chiavi con restrizioni. Tra gli account interessati, 573 potevano accettare pagamenti, 531 potevano effettuare accrediti e 519 potevano svolgere entrambe le operazioni, secondo l’analisi citata nei report.

Perché una sola chiave attiva poteva bastare

Una chiave segreta Stripe è una credenziale per l’accesso alle API, non un semplice identificativo. La portata effettiva dipende dai permessi della chiave e dalla configurazione dell’account, ma una credenziale compromessa può esporre risorse del merchant e consentire attività di pagamento non autorizzate.

Le verifiche descritte nei report hanno mostrato che una singola chiave attiva poteva essere utilizzata per accedere agli elenchi dei clienti, creare link di pagamento fraudolenti ed effettuare addebiti di prova. Tra le conseguenze possibili figurano l’estrazione sistematica dei dati dei clienti, l’abuso dei pagamenti, rimborsi non autorizzati, campagne di phishing mirate e tecniche di ingegneria sociale legate ai pagamenti. Gli account dotati di funzioni di accredito dovevano inoltre verificare con particolare attenzione le impostazioni e le destinazioni dei pagamenti.

Il fattore più critico è la rapidità: una credenziale server-side esposta può trasformare un errore nella gestione dei segreti in un’indagine per frode prima ancora che il merchant rilevi attività anomale.

Perché non sembra una violazione dei sistemi Stripe

Le prove disponibili suggeriscono che gli aggressori abbiano utilizzato credenziali valide dei merchant per recuperare i dati attraverso l’accesso legittimo alle API di Stripe. I ricercatori che hanno esaminato i file offline hanno osservato oggetti in stile Stripe e una struttura delle cartelle coerente con esportazioni ottenute dagli endpoint API; nell’ambito di quella revisione non hanno autenticato le chiavi esposte né effettuato accessi agli ambienti live dei merchant.

La distinzione è importante: il probabile punto di compromissione riguarda la gestione delle credenziali da parte dei merchant, non i sistemi centrali di Stripe. Le possibili vie di esposizione includono:

• infezioni da infostealer sui dispositivi di sviluppatori o amministratori;
• repository pubblici e cronologia di Git;
• file .env e configurazioni dei server esposti;
• archivi cloud, backup e livelli delle immagini container;
• sistemi CI/CD e log di GitHub Actions;
• server configurati in modo errato o scansioni automatiche alla ricerca di variabili esposte.

Il percorso iniziale con cui sarebbero state sottratte le credenziali dei 659 merchant non è stato stabilito. Quelli elencati sono vettori plausibili, non l’origine confermata dell’intero dataset.

Il rilascio collegato e il problema dei conteggi

Secondo i report di Hudson Rock, un’ulteriore pubblicazione sullo stesso forum sarebbe riconducibile allo stesso attore. Il rilascio comprendeva, secondo la descrizione, 669 cartelle di fornitori e 1.033 chiavi API compromesse, per una dimensione pubblicizzata di 33 GB; il download collegato sarebbe stato più piccolo. L’attore ha inoltre dichiarato di possedere circa 20.000 ulteriori chiavi API Stripe compromesse e ha lasciato intendere che potrebbero seguire altri pacchetti.

Questi numeri non devono essere sommati come se rappresentassero un totale verificato. La differenza tra 659 account merchant, 669 cartelle di fornitori e 1.033 chiavi può dipendere da dataset diversi, da più chiavi associate allo stesso account o da metodi di conteggio differenti. La cifra di 20.000 chiavi resta una dichiarazione non verificata dell’attore.

Dove si trovavano i merchant più colpiti

La distribuzione geografica riportata dalle fonti indicava soprattutto:

• Stati Uniti: 212 merchant;
• Regno Unito: 81;
• Francia: 57;
• Canada: 38;
• Brasile: 30;
• Australia: 27.

I conteggi descrivono la distribuzione osservata nei report e devono essere letti insieme alla cautela generale sul perimetro ancora in fase di valutazione.

Cosa devono fare subito le aziende che usano Stripe

1. Ruotare le chiavi segrete live

Revocare e sostituire ogni chiave segreta live che possa essere comparsa nel codice sorgente, nei log, nei backup, nella telemetria degli endpoint, nelle immagini container o nell’infrastruttura pubblica. Non bisogna attendere la comparsa di transazioni fraudolente prima di sostituire una credenziale potenzialmente esposta.

2. Controllare API e operazioni di pagamento

Esaminare i log API e di sicurezza alla ricerca di chiamate insolite, nuovi link di pagamento, addebiti di prova o non autorizzati, rimborsi inattesi, modifiche ai permessi e indirizzi IP anomali. I log rilevanti vanno conservati per consentire agli investigatori di ricostruire la sequenza degli eventi.

3. Verificare le impostazioni degli accrediti

Controllare le impostazioni dei pagamenti in uscita, i dati dei conti bancari collegati e le destinazioni degli accrediti. Eventuali modifiche sospette devono essere segnalate rapidamente a Stripe e agli istituti finanziari, seguendo le procedure applicabili di risposta agli incidenti e di segnalazione.

4. Sostituire le credenziali troppo ampie con chiavi limitate

Usare chiavi con restrizioni, autorizzate solo per le operazioni API necessarie a ciascun servizio. È preferibile separare sistemi di produzione, ambienti di sviluppo e ruoli operativi invece di distribuire un’unica credenziale estesa tra più applicazioni.

5. Cercare i segreti in tutti i luoghi in cui possono sopravvivere

Controllare repository attuali e storici, cronologia Git, output CI/CD, log di GitHub Actions, file .env, livelli container, archivi cloud, documentazione e backup alla ricerca di valori sk_live. Ogni credenziale individuata deve essere revocata e sostituita, anche se non compare più nella versione corrente del codice.

6. Considerare la scansione di GitHub solo come un livello di difesa

GitHub afferma che la scansione dei segreti viene eseguita automaticamente nei repository pubblici, mentre per i repository privati e interni appartenenti a un’organizzazione è necessario GitHub Secret Protection, disponibile sui piani idonei. La scansione non può recuperare segreti già copiati nei log, nei backup, nella telemetria degli endpoint o negli archivi scaricati. Deve quindi affiancare, e non sostituire, la gestione centralizzata dei segreti, credenziali con durata breve, controlli di accesso e monitoraggio continuo.

La lezione per i merchant

Il punto più chiaro è che la sicurezza dei sistemi di pagamento dipende anche dalla corretta gestione delle credenziali da parte dei merchant. I report disponibili non dimostrano una violazione dell’infrastruttura Stripe, ma mostrano come una chiave API live esposta possa aprire la strada all’accesso ai dati dei clienti e all’abuso dei pagamenti. Le credenziali di produzione vanno trattate come asset ad alto impatto: mai inserirle nel codice o nei log, limitarne i permessi, ruotarle rapidamente e indagare ogni attività API o operazione di accredito inattesa.