L’attacco cifrato agli agenti e il rischio SSRF nel tuo repo Bolt

Un payload cifrato può superare il controllo e arrivare fino alla rete

Un gruppo di ricercatori ha mostrato un attacco in cui istruzioni malevole venivano inserite dentro un payload cifrato. Il modello, invece di bloccarle, ha eseguito la decrittazione nel proprio ambiente di codice e ha poi seguito le istruzioni fino a inviare dati verso un URL controllato dall’attaccante. La notizia è raccontata in “Researchers hid an attack inside AES encryption. The AI model cracked it open willingly.”, pubblicato il 20 agosto 2026.

Il dettaglio da founder è questo: il filtro aveva visto testo apparentemente innocuo, ma il sistema nel suo complesso ha trasformato quel contenuto in un’azione. Il problema non era solo ciò che entrava nel modello. Era ciò che il modello poteva fare dopo averlo interpretato.

Se hai spedito un’app con un coding tool, la domanda equivalente è: cosa succede quando il tuo backend riceve un URL o un contenuto esterno e lo va a recuperare per conto dell’utente?

Cosa significa se il tuo codice l’ha scritto Bolt

Immagina un’app costruita con Bolt per importare pagine web, generare anteprime, analizzare feed o trasformare documenti. L’utente incolla un URL, il backend esegue una richiesta HTTP, legge la risposta e la restituisce all’interfaccia.

Il flusso sembra innocuo:

• l’utente invia un indirizzo;
• il server valida che abbia il formato corretto;
• una libreria HTTP scarica il contenuto;
• l’app mostra titolo, testo o metadati.

Il buco tecnico è un SSRF, cioè una richiesta forzata dal server verso una destinazione che l’utente non dovrebbe poter raggiungere. L’URL può puntare a servizi interni, pannelli amministrativi, endpoint cloud o porte accessibili solo dalla rete privata.

Una validazione superficiale non basta. Bloccare localhost può essere inutile se l’attaccante usa 127.0.0.1, una variante IPv6, un hostname che risolve a un indirizzo privato o una catena di redirect. Anche un dominio pubblico può risolvere prima verso un IP consentito e poi cambiare destinazione dopo la validazione.

Bolt non è il problema. Ti aiuta a trasformare rapidamente un’idea in un’app funzionante. Il rischio nasce quando una funzione “importa URL” viene collegata a un server con accesso alla rete interna senza definire con precisione quali destinazioni siano ammesse.

Perché ora ti serve un audit: il verdetto sul percorso della richiesta

Un audit VibeInspect serve a ricostruire il percorso reale tra input, validazione, client HTTP e risposta. Non basta verificare che l’URL venga controllato con una regex. Bisogna capire se il server può essere usato come ponte verso una rete che l’utente non vede.

Nel caso di un SSRF, il verdetto tecnico deve rispondere a domande concrete:

1. Quali route accettano URL, host o destinazioni controllate dall’utente?
2. La richiesta parte dal browser o dal server?
3. La validazione avviene prima della risoluzione DNS?
4. Il codice blocca intervalli privati, loopback, link-local e indirizzi IPv6 equivalenti?
5. I redirect vengono seguiti automaticamente?
6. Il client HTTP può accedere a porte non necessarie?
7. La risposta restituisce header, metadati o contenuti interni?
8. Esistono timeout, limiti di dimensione e limiti sul numero di redirect?
9. L’ambiente di produzione ha accesso a metadata service o credenziali cloud?
10. I log registrano URL e risposte che potrebbero contenere dati sensibili?

Queste domande attraversano più livelli del repository. La route API può sembrare protetta, mentre una libreria segue redirect senza ulteriori controlli. La blacklist può bloccare alcuni indirizzi, ma non impedire una risoluzione DNS verso una rete privata. Il server può rifiutare localhost, ma restare esposto tramite un hostname equivalente.

L’audit pesa proprio perché produce un verdetto sul comportamento complessivo: destinazione raggiungibile, condizioni necessarie, impatto e punti del codice che sostengono l’evidenza. Non è una promessa astratta e non è un pentest.

Per un buco tecnico come questo, il piano coerente è il Diagnostic da €499: restituisce file, righe ed evidenze. Lo Snapshot da €49 offre uno score iniziale, ma non localizza il percorso SSRF. L’audit genera un PDF con il verdetto; non modifica il codice.

Cosa un linter non vede

Un linter può segnalare una chiamata HTTP senza gestione degli errori, un tipo non valido o una funzione complessa. Non sa se l’URL passato a quella chiamata può risolvere verso 169.254.169.254, una rete aziendale o un pannello admin.

Non vede nemmeno la differenza tra validare una stringa e governare una destinazione. Una funzione come:

fetch(userUrl)

può essere perfettamente valida dal punto di vista sintattico e restare pericolosa dal punto di vista architetturale.

Il problema vive nella sequenza:

• il server interpreta l’input;
• risolve il dominio;
• apre una connessione;
• segue eventualmente un redirect;
• riceve contenuto non fidato;
• lo passa ad altri componenti o a un modello;
• restituisce parte della risposta all’utente.

Un linter non ricostruisce questo flusso. Non sa se il parser URL gestisce correttamente credenziali incorporate, porte insolite o rappresentazioni alternative degli indirizzi. Non sa se il client HTTP segue redirect verso una destinazione vietata. Non sa se il contenuto recuperato viene poi passato a un agente con accesso a dati privati o strumenti esterni.

Lo stesso vale per i controlli basati solo sul testo. L’attacco descritto dalla fonte mostra che un contenuto può cambiare significato durante l’elaborazione: da ciphertext a istruzione, da output di uno strumento a comando operativo. Il controllo deve quindi esistere anche sul punto in cui l’azione viene eseguita, non soltanto sul testo iniziale.

Un audit collega input, rete, autorizzazioni, strumenti e dati. È lì che emerge la risposta che manca: il tuo server scarica solo risorse pubbliche consentite oppure può diventare un proxy verso l’interno?

Cosa fare questa settimana

Prima di spedire una funzione di importazione, anteprima o analisi URL nel tuo progetto Bolt, fai queste verifiche:

1. Elenca tutte le route che fanno fetch server-side. Includi immagini, PDF, feed, webhook e URL inseriti nei prompt.
2. Definisci una allowlist. Se possibile, consenti solo domini e schemi strettamente necessari.
3. Blocca le reti private dopo la risoluzione DNS. Non affidarti soltanto a una blacklist testuale.
4. Gestisci i redirect manualmente. Rivalida ogni nuova destinazione prima di seguirla.
5. Limita porte, timeout e dimensione delle risposte. Un fetch non deve avere accesso illimitato alla rete.
6. Separa il fetch dagli strumenti dell’agente. Un contenuto esterno non dovrebbe poter trasformarsi direttamente in un’azione privilegiata.
7. Controlla i log. URL, header e risposte non devono diventare una nuova superficie di esposizione.
8. Chiedi un verdetto prima del go-live. Se non sai indicare quali destinazioni sono consentite, il confine non è ancora definito.

Se hai spedito con Bolt e il tuo prodotto accetta URL, contenuti esterni o richieste elaborate dal server, carica lo ZIP su VibeInspect.ai. Riceverai un audit on-demand con verdetto in PDF e il sorgente verrà cancellato a fine analisi.

Scegli il Diagnostic se vuoi evidenze file/riga sul percorso SSRF, sui redirect o sui confini di rete. Il problema non è aver usato l’AI per costruire l’app: è lasciare che un input apparentemente innocuo decida dove il tuo server può andare.