Adobe hackerata: 13 milioni di ticket, dati personali e altre vulnerabilità sono nelle mani di "Mr. Raccoon" (aggiornato: 3 aprile 2026, ore 18:14)

Un attore malevolo che si fa chiamare «Mr. Raccoon» sostiene di aver sottratto ad Adobe oltre 13 milioni di ticket di assistenza clienti, dati su 15.000 dipendenti, documenti interni e - dettaglio potenzialmente esplosivo - l'intero archivio delle segnalazioni di vulnerabilità inviate tramite la piattaforma HackerOne. Il punto di ingresso non sarebbe stato un attacco diretto all'infrastruttura di Adobe, ma la compromissione di un'azienda indiana alla quale era stata affidata la gestione del supporto clienti. Adobe, al momento, non ha rilasciato alcun commento ufficiale.

L'attacco: phishing chirurgico e un RAT silenzioso

La catena di compromissione descritta da Mr. Raccoon segue uno schema classico ma efficace. Prima mossa: un'email malevola inviata a un dipendente della società indiana compromessa, che ha installato silenziosamente un Remote Access Tool (RAT) sulla macchina della vittima. Questo strumento ha fornito all'attaccante il controllo remoto completo del dispositivo, incluso l'accesso alla webcam e l'intercettazione dei messaggi WhatsApp privati.

Poi l'escalation: un messaggio di spear-phishing mirato al responsabile diretto del dipendente già compromesso. Una mossa calcolata per penetrare più in profondità e, di conseguenza, nei sistemi a cui quell'operatore aveva accesso legittimo per conto di Adobe.

La notizia è stata diffusa il 2 aprile 2026 dall'account X International Cyber Digest (@IntCyberDigest), il cui il team afferma di aver esaminato diversi file che confermerebbero la portata della violazione. Tutte le fonti successive attingono a questa segnalazione originale. Nessuna verifica tecnica indipendente è stata pubblicata finora.

Tredici milioni di ticket e zero controlli sull'esportazione

Il dato più sconcertante non riguarda la quantità di informazioni sottratte - circa 13 milioni di ticket di supporto contenenti nomi, indirizzi email, dettagli degli account e descrizioni di problemi tecnici - ma la facilità con cui sarebbero stati esfiltrati. Mr. Raccoon lo ha spiegato senza giri di parole a International Cyber Digest che la piattaforma di ticketing di Adobe «permetteva di esportare tutti i ticket con una sola richiesta dell'agente».

Nessun limite di frequenza, nessun avviso di sicurezza, nessun controllo di autorizzazione. Un singolo account compromesso poteva aspirare milioni di record senza che scattasse alcun allarme né fosse necessaria l'approvazione di un supervisore.

Se confermato, è un errore di configurazione grave. Qualsiasi architettura di sicurezza minimamente ragionevole prevede controlli sul volume delle esportazioni, segmentazione degli accessi e meccanismi di rilevamento anomalie. L'assenza simultanea di tutti e tre suggerisce una lacuna strutturale nella supervisione dei fornitori terzi, non un incidente isolato.

Il nodo HackerOne: vulnerabilità come armi

Tra i dati che Mr. Raccoon afferma di possedere ci sarebbero tutte le segnalazioni inviate al programma bug bounty di Adobe su HackerOne. È il pezzo più pericoloso dell'intero puzzle.

Le sottomissioni di HackerOne contengono descrizioni dettagliate, passo dopo passo, di vulnerabilità scoperte da ricercatori di sicurezza indipendenti - molte delle quali riguardano falle corrette prima della divulgazione pubblica. Se alcune risultassero ancora senza patch al momento della sottrazione, chiunque ne entri in possesso disporrebbe di un arsenale pronto all'uso contro i prodotti Adobe e, per estensione, contro i loro milioni di utenti.

Il problema sistemico della supply chain

Questo presunto attacco non ha preso di mira i server di Adobe, ma ha colpito un anello a valle: un'azienda di outsourcing in India i cui dipendenti avevano evidentemente accesso ampio ai sistemi del committente.

Il nome specifico della società indiana non è stato reso noto da nessuna delle fonti disponibili. Si parla solo di Business Process Outsourcing (PBO), ma questa parrebbe essere la categoria generale di aziende che offre servizi di supporto ad altre aziende, non un nome proprio.

Ad ogni modo: il modello è tristemente familiare. Le grandi aziende tecnologiche esternalizzano porzioni consistenti del supporto clienti a fornitori terzi, spesso in paesi dove il costo del lavoro è inferiore. Questi fornitori operano con credenziali che garantiscono accesso a dati sensibili, senza essere sempre sottoposti agli stessi standard di sicurezza della casa madre. L'attaccante non ha bisogno di violare le difese del bersaglio principale: basta trovare il punto più debole della catena.

La domanda non è se Adobe avrebbe dovuto esternalizzare il supporto. La domanda è quali controlli tecnici e organizzativi fossero in atto per limitare il raggio d'azione di un singolo account compromesso presso un fornitore. L'esportazione di massa senza restrizioni suggerisce che la risposta sia: non abbastanza.

Cosa sappiamo e cosa no

Al momento tutte le affermazioni di Mr. Raccoon sono non-verificate. Nessuna autorità indipendente ha confermato la violazione. Nessuna fonte ha accesso indipendente ai dati oltre a quanto mostrato da International Cyber Digest. Adobe non ha confermato né smentito.

Non è noto se i dati sottratti siano stati pubblicati, messi in vendita o condivisi in forum underground. Non è noto l'arco temporale della presunta intrusione né quanti dei 13 milioni di ticket contengano informazioni ancora attuali e sfruttabili. I 15.000 record dei dipendenti - il cui contenuto specifico non è stato dettagliato - rappresentano un'ulteriore incognita sulla portata del danno potenziale.

Se Adobe dovesse confermare anche solo una parte di queste affermazioni, il caso diventerebbe uno dei più significativi incidenti di sicurezza legati alla catena di fornitura degli ultimi anni. Non per la sofisticazione dell'attacco - un RAT e dello spear-phishing non sono esattamente tecniche d'avanguardia - ma per la sproporzione tra la semplicità del vettore d'ingresso e l'enormità dei dati raggiungibili. Una sproporzione che chiamerebbe in causa direttamente le scelte architetturali di chi quei sistemi li ha progettati e di chi avrebbe dovuto vigilare su chi li utilizzava.

Fonti: cyberpress.org, cybersecuritynews.com, securityonline.info