iOS AI apps: 282 esposte, solo 28% corregge

Studio Wake Forest: 282 app iOS LLM su 444 analizzate espongono credenziali API. Dopo 90 giorni di disclosure, solo il 28% ha corretto. Il 23% resta exploitabile.

Uno studio accademico condotto da ricercatori di Wake Forest University ha rilevato che 282 applicazioni iOS con funzionalità di large language model, pari al 64% di un campione di 444 app analizzate, esponevano credenziali API o meccanismi di accesso backend intercettabili. Il 22 giugno 2026 le prime coverage editoriali hanno reso pubblici i risultati del retest a 90 giorni dalla responsible disclosure: solo 78 app, il 28%, avevano corretto le vulnerabilità. Il restante 23% risultava ancora pienamente exploitabile, per inazione dei developer o per implementazioni di autenticazione fondamentalmente difettose.

Punti chiave

282 app iOS LLM su 444 analizzate esponevano credenziali o accessi backend intercettabili, con 146 classificate come pienamente exploitabili
Dopo disclosure responsabile a 282 sviluppatori e retest a 90 giorni, solo il 28% ha corretto; il 23% resta exploitabile
Tre pattern di leakage dominano: API key in plaintext, JWT con validità eccessiva, backend proxy senza autenticazione che fungono da open relay
L'app più popolare tra quelle vulnerabili supera i 2,3 milioni di ratings, e il 15% delle app a rischio ha più di 1.000 valutazioni

LLMKeyLens: come funziona il framework di analisi

I ricercatori hanno sviluppato LLMKeyLens, un framework per intercettare il traffico di rete delle app iOS, rilevare API key specifiche per provider, token di autenticazione ed endpoint backend esposti, e validare l'effettiva abusabilità delle credenziali leakate. Il campione è stato costruito a partire da oltre 38.000 listing dell'App Store, ridotti a più di 5.600 app AI-related, poi filtrati a 444 con integrazione LLM confermata attraverso analisi dinamica.

La metodologia ha isolato tre pattern di leakage convergenti. Cinquantaquattro app esponevano API key in plaintext nel client iOS, intercettabili tramite network traffic analysis. Centotrentasei app rivelavano authentication tokens, in un caso con JWT a validità superiore a 100 anni. Novantadue app utilizzavano backend proxy che, pur nascondendo correttamente le API key, non richiedevano autenticazione dal client, trasformandosi di fatto in open relay.

Ventotto delle app con API key in plaintext esponevano anche system prompt proprietari, espandendo la superficie di attacco oltre la semplice usabilità delle credenziali. Centocinquantacinque app vulnerabili utilizzavano backend custom sviluppatori, 67 si appoggiavano a cloud platform come Firebase, Google Cloud Run o AWS, e 60 comunicavano direttamente con provider AI senza intermediari architetturali.

Dati del campione: distribuzione e popolarità

La vulnerabilità non è circoscritta a app di nicchia. Il 15% delle app vulnerabili ha più di 1.000 user ratings, e l'app più popolare nel campione supera i 2,3 milioni di ratings. Productivity apps rappresentano la categoria più numerosa di app a rischio, mentre Health & Fitness registra il tasso più alto di leakage in proporzione alle app analizzate nella categoria.

Le app LLM-powered hanno raggiunto 17 miliardi di download nel 2025, pari al 13% di tutti i mobile app download. Questa adozione di massa rende il leakage di credenziali non un incidente marginale ma un problema sistemico nell'ecosistema iOS, con impatti che si propagano da developer ignoti a utenti mainstream.

"LLM API key leakage is a widespread and systemic issue in the iOS ecosystem, affecting 26% of analyzed Apps across diverse categories and developer types. The vulnerability's impact extends from niche Apps to popular apps with hundreds of thousands of users"

Il fallimento del retest: cosa succede dopo la disclosure

I ricercatori hanno notificato responsabilmente le 282 app vulnerabili e hanno condotto un retest a 90 giorni. Il risultato è uno spaccato della inefficacia della disclosure tradizionale in un contesto mobile frammentato. Settantotto app, il 28%, avevano corretto tramite revoca delle credenziali o enforcement di access control.

Trentasei app non avevano intrapreso alcuna azione di remediation. Trenta avevano implementato contromisure tecnicamente insufficienti, con autenticazione fondamentalmente difettosa che non impediva l'abuso continuato delle credenziali o dell'accesso backend. Complessivamente, il 23% del campione vulnerabile restava exploitabile al termine del periodo di osservazione.

I ricercatori hanno evidenziato un dato architetturale rilevante: il 55% delle app con leakage instrada il traffico LLM attraverso backend custom sviluppatore, rendendo insufficienti le mitigazioni esclusivamente lato provider. Cloud platform e servizi API diretti rappresentano rispettivamente il 23% e il 21% del leakage, confermando che l'adozione di una proxy architecture non preclude di per sé l'esposizione delle credenziali.

"Over half of leaked Apps (55%) route LLM traffic through custom developer backends, making provider-side mitigations alone insufficient. Cloud platforms and direct API services account for comparable shares of leakage (23% and 21%, respectively), confirming that adopting a proxy architecture does not prevent credential exposure"

Perche è importante

Lo studio solleva interrogativi strutturali sulla governance della sicurezza nell'App Store. La responsible disclosure, intesa come notifica diretta agli sviluppatori, ha prodotto remediation in meno di un terzo dei casi. Il tempo di osservazione di 90 giorni non è arbitrario: rappresenta una finestra standard nel calendario di disclosure accademica, ma i risultati indicano che per quasi tre quarti delle app vulnerabili non è stato sufficiente a generare fix effettivi.

Il dossier non specifica se Apple abbia risposto alla ricerca o progetti di integrare detection di credenziali leakate nel review process dell'App Store. Non emergono sovrapposizioni infrastrutturali che colleghino le app vulnerabili a specifici framework di sviluppo o a pratiche di codifica documentate. Il brief non documenta misure correttive specifiche adottate dai provider LLM per revocare credenziali esposte a livello di API.

La natura dei dati esposti varia per pattern di leakage. API key in plaintext abilitano costi API diretti a carico dello sviluppatore e potenziale data poisoning delle risposte del modello. Backend proxy non autenticati espongono l'infrastruttura a uso arbitrario, con rischi di violazione della riservatezza degli utenti finali che transitano per l'app. JWT con validità eccessiva abilitano replay attack prolungati nel tempo.

La fonte non specifica la natura completa dei dati utente transitanti attraverso i backend vulnerabili, né quantifica l'entità economica del danno potenziale derivante dall'exploitation delle credenziali leakate. Il paper accademico originale non è accessibile direttamente attraverso le fonti editoriali disponibili; i dati tecnici riportati sono ricostruiti dalle coverage di Help Net Security e CyberInsider, convergenti ma non verificabili sul primario scientifico.

Lettura: oltre la singola advisory

Il caso Wake Forest non è una vulnerabilità software patchabile con un aggiornamento. È un campione di pratiche di integrazione LLM difettose distribuite su centinaia di app indipendenti, con governance di sicurezza decentralizzata e nessun meccanismo coercitivo di enforcement. La bassa quota di remediation suggerisce che la disclosure responsabile, pur eticamente corretta, opera in un vuoto istituzionale quando il destinatario è uno sviluppatore individuale senza incentivi strutturali alla compliance.

La prospettiva del lettore aziendale è duplice. Per chi sviluppa app LLM-powered: il leakage è un problema di architettura, non di configurazione singola. La presenza di credenziali nel client iOS, la mancata scadenza dei token, l'assenza di autenticazione su backend proxy sono pattern evitabili in fase di design. Per chi consuma servizi LLM tramite terze parti: le credenziali esposte appartengono allo sviluppatore dell'app, ma l'abuso si traduce in manipolazione dei contenuti e potenziale esfiltrazione dei dati inseriti dall'utente.

Il dato architetturale più rilevante è che nessun pattern di integrazione è intrinsecamente protetto. Backend custom, cloud platform, comunicazione diretta con provider: tutte e tre le modalità presentano app vulnerabili nel campione. La sicurezza dipende dai controlli di autenticazione e autorizzazione implementati, non dalla scelta infrastrutturale.

Domande frequenti

Le app vulnerabili sono state effettivamente sfruttate da attori malevoli?: Le fonti documentano che le app erano exploitabili attraverso richieste benigne, non confermano exploitation attiva in-the-wild. Il retest ha validato la persistenza delle vulnerabilità, non l'avvenuto abuso.
Posso verificare se un'app specifica è nel campione?: Non è disponibile. I ricercatori non hanno divulgato l'elenco delle 282 app per preservare la responsible disclosure.
I provider LLM possono bloccare le credenziali esposte?: Per il 55% delle app con backend custom, le credenziali appartengono allo sviluppatore e non transitano direttamente lato provider. In questi casi la revoca è possibile solo a monte del proxy sviluppatore.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti