Un agente AI ha trovato un bypass OTP che il pentest umano aveva mancato

Un agente di pentest AI, lanciato in autonomia contro il sito di produzione di un grande assicuratore, ha trovato un bypass di autenticazione critico che un penetration test umano aveva mancato circa sei mesi prima. La falla era quasi imbarazzante nella sua semplicità: il flusso di login lasciava che fosse la richiesta a decidere dove veniva recapitato il codice usa e getta (OTP). La parte difficile — quella che fa di questa una vera storia di ingegneria e non una demo — era dimostrare che il bypass funzionasse su un sito vivo, con milioni di clienti, senza toccare un solo account reale.

Notizia in evoluzione — pubblicata alle 17:35 (15:35 UTC) del 14 ottobre 2026. Aggiornata man mano che emergono dettagli tecnici.

Il racconto arriva da Reflectiz, il cui co-fondatore e CTO Ysrael Gurt ha descritto la scoperta in un contributo pubblicato su The Hacker News il 14 ottobre. I dettagli vanno letti come il resoconto del vendor su un ingaggio autorizzato — ma il meccanismo è da manuale, e la lezione che sta sotto è la parte che vale la pena tenere.

Cosa ha trovato davvero l'agente di pentest AI

Secondo Reflectiz, l'agente è partito dalla ricognizione: ha letto il JavaScript lato client del sito e mappato le chiamate API dietro le pagine di login. È così emersa la richiesta OTP e, al suo interno, due valori che controllavano il recapito. Uno selezionava il canale; uno trasportava l'indirizzo di destinazione.

In uso normale, il codice veniva inviato via SMS al numero di telefono registrato sull'account. Ma la richiesta poteva cambiare il canale in email e mandare il codice a qualunque indirizzo indicato. Il server non verificava mai che quell'indirizzo appartenesse all'account. Un attaccante già in possesso dei giusti identificativi del cliente poteva dirottare il codice di login della vittima verso una casella sotto il proprio controllo, leggerlo, e completare l'accesso come quell'utente.

È un classico cedimento dell'autenticazione — l'OTP era trattato come un segreto in transito, ma la destinazione del segreto era controllabile dall'attaccante. La Web Security Testing Guide di OWASP da anni dice ai tester di verificare esattamente questo: che il secondo fattore sia legato all'account corretto e non possa essere reindirizzato. È il tipo di controllo che un tester umano scrupoloso dovrebbe fare — e che, su questo sito, a quanto pare non è stato fatto, o è stato fatto e archiviato.

"L'attacco era la parte facile" è la lezione vera

L'agente non si è limitato a segnalare un parametro sospetto e aprire un ticket. Stando a Reflectiz, ha trattato i due valori di recapito come un'ipotesi, ha costruito un test mirato e l'ha fatto girare nel flusso di login reale: ha richiesto un codice, lo ha indirizzato a una casella che controllava, ed è entrato. Una guardia ha poi fermato l'esecuzione nel momento esatto in cui il login è riuscito — abbastanza da dimostrare il bypass, non un passo oltre.

Quella sequenza è più difficile di quanto sembri, ed è il punto in cui la maggior parte delle demo di "pentest autonomo" si ferma in silenzio:

• Il login è un flusso autenticato a più passi, non una singola richiesta da fuzzare.
• Dimostrare il bypass significa ricevere e gestire davvero un codice di verifica reale a metà del flusso.
• Farlo in produzione significa farlo senza compromettere, bloccare o inondare account di clienti reali.

"Uno scanner può dirti che un parametro sembra interessante. Non può dirti se, su questa build, un estraneo può entrare come te. L'unico modo per saperlo è eseguire la catena — e fermarsi esattamente alla riga giusta."

Reflectiz afferma che un agente validatore separato ha poi riprodotto la scoperta con lo stesso payload e lo stesso contesto prima che venisse riportata, e che l'ingaggio ha prodotto un registro di copertura di cosa è stato testato, con quale esito e cosa è stato deliberatamente escluso. Quella disciplina del riprodurre-prima-di-riportare è la differenza tra una scoperta su cui un ingegnere può agire e un falso positivo che brucia la fiducia di un team di sicurezza.

Perché conta proprio adesso

Il login con OTP presso gli assicuratori è sotto attacco reale, non sotto una pressione ipotetica. A luglio 2026 CTM360 ha documentato un kit di phishing-as-a-service — "InsureOTP" — che rilancia in tempo reale i codici usa e getta delle vittime contro veri portali assicurativi, concentrato in Arabia Saudita con attività in Europa, Stati Uniti e India. Gli attaccanti stanno già industrializzando il furto degli OTP. Un flusso di login che spedisce il codice a chiunque lo chieda è un regalo proprio per quell'ecosistema — senza bisogno di alcuna pagina di phishing.

Remediation

Se il tuo flusso di autenticazione lascia che sia il client a influenzare dove va un codice, hai questo bug. La correzione è precisa.

Sono interessato? Ispeziona ogni endpoint di invio OTP/MFA. Il corpo della richiesta può specificare il canale di recapito o l'indirizzo di destinazione? Il server ricava la destinazione dal record dell'account autenticato, o si fida di un campo fornito dal client? Se la destinazione arriva dalla richiesta, sei esposto.

Correzione. Non accettare mai una destinazione OTP fornita dal client in fase di autenticazione. Ricava canale e indirizzo lato server dal contatto verificato e registrato sull'account. Tratta la modifica di un canale o di un indirizzo di recapito come un'operazione sensibile che richiede ri-autenticazione e step-up — mai come effetto collaterale di una richiesta di login.

Controlli compensativi nel frattempo. Porta gli account di alto valore su MFA resistente al phishing e legato all'origine (FIDO2/passkey), che neutralizza sia questo dirottamento sia il rilancio in stile InsureOTP, perché un codice inserito sull'origine sbagliata è inutile. Applica rate-limit sugli invii OTP e genera un alert quando la destinazione richiesta è diversa dal contatto registrato.

Caccia agli abusi. Esamina i log di invio OTP per richieste la cui destinazione non corrisponde al contatto registrato dell'account, e per login riusciti preceduti da un codice inviato a un indirizzo non corrispondente. Mappa su MITRE ATT&CK T1621 (Multi-Factor Authentication Request Generation), T1556 (Modify Authentication Process) e T1078 (Valid Accounts).

Verifica. Ri-testa il flusso corretto con lo stesso payload che ha dimostrato il bug. La correzione è confermata solo quando il codice può raggiungere soltanto la destinazione ricavata lato server, qualunque cosa chieda la richiesta.

Cosa non si sa ancora

L'assicuratore non è nominato e la scoperta è riportata attraverso il resoconto del vendor; i parametri di richiesta coinvolti non sono stati pubblicati, non c'è un CVE né una conferma indipendente di portata o stato della remediation. Se la falla sia stata corretta del tutto, e se sia mai stata sfruttata in natura, non è pubblico.

Eseguire per primi lo stesso attacco

La parte scomoda di questa storia non è che un'AI abbia trovato il bug. È che un pentest umano, sei mesi prima, non l'avesse trovato — e che un singolo test annuale o trimestrale sia l'intera garanzia che la maggior parte dei flussi di login di produzione riceve mai. Un agente autonomo capace di ri-eseguire in sicurezza, e in continuo, il playbook dell'attaccante è ciò che chiude quel divario.

È il problema per cui è costruito il red team AI autonomo di Zero Hunt. Lo sciame di 10 agenti esegue la ricognizione, trova la debolezza raggiungibile dall'input e — tramite un coding agent sigillato — itera un proof-of-concept finché non funziona in modo dimostrabile, la stessa disciplina del riprodurre-prima-di-riportare che rende affidabile una scoperta. Ogni PoC gira dentro un container effimero con hardening gVisor opzionale, così dimostrare un bypass non mette mai a rischio l'host o gli utenti reali; ogni azione che supera una soglia attende un gate con human-in-the-loop; ogni risultato è firmato al momento della scrittura (Ed25519, concatenato per hash) perché l'evidenza regga anche dopo. Flussi autenticati a più passi come il login di questo assicuratore sono territorio gray-box — credenziali reali, sequenze di login reali — mentre il motore opera in black-box per impostazione predefinita. Tutto gira sull'apparato on-premise su modelli privati, così il traffico autenticato e gli identificativi dei clienti che maneggia non lasciano mai l'apparato, e non esiste una terza parte che possa rallentare o spegnere la capacità. È così che il penetration testing automatico smette di essere un'istantanea annuale e diventa qualcosa che avrebbe intercettato tutto questo già nella prima settimana. Se il tuo flusso di login decide dove va il codice, facci dimostrare cosa potrebbe farne un attaccante — in sicurezza.