Kiro eseguiva codice da pagine avvelenate mentre Apple esponeva le email reali

🛡️ Executive Summary

• Una pagina web con istruzioni nascoste poteva indurre Kiro a modificare la configurazione MCP ed eseguire codice con i privilegi dello sviluppatore.
• Apple ha corretto Hide My Email: i messaggi respinti come spam potevano registrare nei log l’indirizzo reale dell’utente.
• AWS corregge inoltre due falle in s2n-tls e una denial of service nei deserializzatori generati attraverso smithy-rs.

AWS ha corretto una vulnerabilità nell’IDE agentico Kiro che permetteva a una pagina web avvelenata di trasformare una normale richiesta di riepilogo in esecuzione di codice sul computer dello sviluppatore. L’attacco sfruttava la prompt injection indiretta per modificare il file di configurazione dei server Model Context Protocol, superando di fatto il controllo umano previsto dal prodotto. Parallelamente, Apple ha risolto una falla in Hide My Email che poteva esporre gli indirizzi reali nei log dei server di posta. Due nuovi bollettini AWS riguardano infine s2n-tls e smithy-rs, con impatti su TLS 1.3, QUIC e servizi Rust.

Una pagina nascosta riscriveva la configurazione MCP di Kiro

L’attacco contro Kiro iniziava quando uno sviluppatore chiedeva all’agente di leggere, cercare o riassumere una pagina web. I ricercatori di Intezer e Kodem Security hanno inserito istruzioni malevole in un testo bianco grande un solo pixel, invisibile alla persona ma acquisito dal modello insieme al resto della documentazione. Kiro interpretava il blocco nascosto come un’attività operativa e utilizzava lo strumento fsWrite per modificare il file ~/.kiro/settings/mcp.json, contenente l’elenco dei server MCP e i comandi necessari ad avviarli. Poiché l’IDE ricaricava automaticamente la configurazione dopo ogni modifica, l’attaccante poteva registrare un falso server MCP il cui comando di avvio eseguiva codice arbitrario sul sistema. Il meccanismo riproduce la stessa classe di rischio osservata nella prompt injection indiretta trasmessa agli agenti AI attraverso repository e contenuti esterni: l’agente tratta dati non fidati come istruzioni e usa capacità legittime per oltrepassare il proprio confine operativo. Nel proof-of-concept il payload si limitava a inviare periodicamente hostname, nome utente e piattaforma, ma avrebbe potuto sottrarre codice sorgente, credenziali e token oppure installare persistenza.

Il popup di conferma non fermava l’esecuzione

Il modello di sicurezza di Kiro prevedeva che le operazioni rischiose venissero sottoposte all’approvazione dello sviluppatore, ma la modifica di mcp.json poteva essere eseguita autonomamente. In alcuni test compariva una finestra che segnalava il cambiamento della configurazione, tuttavia il file veniva ricaricato indipendentemente dalla decisione presa dall’utente. L’unica azione realmente autorizzata dalla vittima era quindi l’apertura della pagina web, non l’installazione e l’esecuzione del server malevolo. La catena funzionava in una o due prove nonostante il comportamento non deterministico del modello e interessava ancora Kiro 0.9.2 su macOS e 0.10.16 su Ubuntu quando la vulnerabilità venne segnalata l’11 febbraio 2026. I ricercatori hanno confermato la correzione nella versione 0.11.130, mentre le build attuali appartengono alla linea 1.0. AWS ha protetto mcp.json, .vscode/tasks.json, la directory .git e altri percorsi sensibili, imponendo l’approvazione esplicita prima della scrittura sia in modalità Autopilot sia in Supervised. La vicenda rafforza quanto emerso con le vulnerabilità degli agenti di coding capaci di eseguire codice dai repository clonati: il controllo efficace deve risiedere nella piattaforma e non dipendere dalla capacità del modello di riconoscere un’istruzione ostile.

Kiro mostra una classe di vulnerabilità ricorrente negli IDE agentici

La vulnerabilità non rappresenta il primo caso in cui Kiro modifica file che determinano quali comandi l’ambiente può eseguire. Già nel 2025 una prompt injection poteva scrivere nella configurazione MCP o in .vscode/settings.json, mentre CVE-2026-10591 consentiva di depositare istruzioni in .vscode/tasks.json e ottenere esecuzione automatica all’apertura di una cartella. Altre correzioni hanno interessato directory di progetto costruite per eseguire codice, helper GitLab vulnerabili alla command injection e permessi troppo aperti sul file contenente i token di autenticazione. Questa successione mostra un problema architetturale comune agli IDE agentici: lo stesso sistema interpreta input esterni, modifica il workspace, esegue shell command e configura strumenti dotati di accesso a servizi aziendali.

L’integrazione con MCP estende ulteriormente l’impatto, perché un server può raggiungere database, API, repository e infrastrutture cloud. La pressione crescente sulle vulnerabilità di AWS AgentCore, Strands e degli strumenti AI conferma che l’approvazione umana non può essere considerata una difesa sufficiente quando l’azione rilevante avviene prima del popup o attraverso un percorso implicitamente autorizzato. Gli sviluppatori devono aggiornare Kiro, limitare i server MCP ammessi, utilizzare ambienti isolati e impedire agli agenti di accedere a segreti di produzione non necessari.

Apple corregge Hide My Email dopo oltre un anno

Apple ha corretto il 3 luglio 2026 una vulnerabilità del servizio Hide My Email, segnalata inizialmente il 13 giugno 2025. La funzione inclusa in iCloud+ genera indirizzi casuali che inoltrano i messaggi verso la casella personale dell’utente, evitando di comunicare il recapito reale a siti, applicazioni e newsletter. Il difetto permetteva però di recuperare l’indirizzo nascosto inviando un messaggio destinato a essere respinto come spam: durante il bounce, alcuni server registravano nei log il vero account utilizzato per l’inoltro. La vittima poteva non accorgersi dell’esposizione, perché il messaggio bloccato non raggiungeva necessariamente la posta in arrivo o la cartella spam. Gli indirizzi collegati ad alias creati prima della correzione potrebbero quindi essere rimasti memorizzati nei mail transfer log di servizi esterni. La falla era stata già ricostruita nell’analisi sulla vulnerabilità di Nascondi la mia email e sull’esposizione degli indirizzi reali, ma Apple avrebbe tentato due correzioni non risolutive prima del fix definitivo. Il caso ha inoltre generato una class action che contesta la commercializzazione di una garanzia di privacy non pienamente rispettata.

AWS corregge TLS 1.3, QUIC e i servizi generati con Smithy

I bollettini AWS 2026-062 e 2026-061 riguardano componenti differenti dalla vulnerabilità Kiro, ma richiedono ugualmente attenzione. CVE-2026-16317 interessa s2n-tls fino alla versione 1.7.5: la mancata validazione del content_type esterno dei record cifrati TLS 1.3 permette a un attaccante man-in-the-middle attivo di eliminare singoli record applicativi senza che client e server rilevino la modifica. Il valore veniva fissato direttamente nei dati autenticati invece di usare il byte ricevuto sulla rete, lasciando quest’ultimo fuori dalla protezione del tag AEAD. CVE-2026-16318 provoca invece una perdita di memoria quando una connessione QUIC attraversa un HelloRetryRequest, con aumento progressivo del consumo nei processi server di lunga durata. Entrambi i problemi sono corretti in s2n-tls 1.7.6. Il terzo difetto, CVE-2026-15957, riguarda i deserializzatori JSON, CBOR e XML generati da smithy-rs: una richiesta piccola ma profondamente annidata può esaurire lo stack e terminare il processo senza autenticazione. AWS ha corretto il problema nella release 2026-06-02 dell’SDK Rust e non indica mitigazioni alternative all’aggiornamento. Le tre falle mostrano che la superficie AWS non riguarda soltanto i servizi cloud visibili, ma anche librerie open source e codice generato incorporati nelle applicazioni dei clienti.