Prompt injection cifrata: il rischio nascosto nel tuo repo Replit

Un attacco nascosto dentro un payload cifrato ha portato un modello a ricostruire istruzioni malevole e a inviare dati di sessione verso un server controllato dall’attaccante. È il punto centrale dell’articolo “Researchers hid an attack inside AES encryption. The AI model cracked it open willingly.”: filtrare il testo in ingresso non basta se il contenuto pericoloso riappare dopo una chiamata a un tool.

Per chi ha spedito con Replit, la domanda non è se il proprio modello sappia riconoscere una prompt injection. La domanda è più concreta: cosa può fare il tuo backend quando riceve un URL, scarica una pagina, esegue una trasformazione o restituisce al modello il risultato di un tool?

Il problema non è solo il prompt: è il percorso che il dato compie

Un’app costruita rapidamente in Replit può avere un endpoint apparentemente innocuo:

• riceve un URL dall’utente;
• esegue un fetch dal server;
• estrae testo o JSON;
• passa il risultato a un modello;
• restituisce una sintesi nella UI.

Il flusso funziona. Il test con un URL pubblico funziona. Il codice è leggibile.

Ma se quell’endpoint può raggiungere indirizzi interni, seguire redirect senza limiti o accettare qualsiasi schema, hai un possibile SSRF, cioè Server-Side Request Forgery. Un attaccante può usare il tuo server come proxy per interrogare servizi interni, endpoint di metadata del cloud, pannelli amministrativi o sistemi accessibili solo dalla rete privata.

La notizia sul payload cifrato aggiunge un dettaglio importante: l’input pericoloso non deve restare visibile nella pagina o nella richiesta iniziale. Può essere ricostruito dentro un tool approvato, trasformato in output e poi usato per guidare l’azione successiva. Se il tuo repo Replit concede al modello accesso a un fetcher troppo permissivo, il confine tra “leggi questa pagina” e “contatta questa destinazione” può sparire.

Cosa significa se il tuo codice l’ha scritto Replit

Non significa che Replit sia insicuro per definizione. Significa che il percorso prompt → tool → rete → risposta va verificato come sistema, non come singolo frammento.

Il buco tecnico da cercare è preciso: un proxy server-side controllato dall’utente che può effettuare richieste verso destinazioni non autorizzate.

Un esempio tipico è una route come /api/preview?url=... o /api/summarize, dove il server prende l’URL dal client e lo passa direttamente a fetch. In una prima versione del prodotto può sembrare una scelta pratica: l’utente incolla un link, il backend scarica la pagina e l’AI la riassume.

Il problema nasce quando mancano controlli come:

• allowlist di domini o schemi consentiti;
• blocco di localhost, IP privati e range riservati;
• gestione sicura dei redirect;
• timeout e limiti di risposta;
• separazione tra contenuto remoto e istruzioni del sistema;
• divieto di includere header o credenziali interne nella richiesta;
• controllo sulle destinazioni finali dopo la risoluzione DNS.

Se l’endpoint può raggiungere una rete interna, una prompt injection non deve convincere il modello a “fare hacking”. Le basta spingerlo verso un tool già disponibile, con parametri scelti dall’attaccante. Il tool fa il resto.

Perché ora ti serve un audit sul repo

Qui l’audit è il passaggio che manca tra “il chatbot risponde” e “il prodotto può trattare dati reali”. Un audit VibeInspect ricostruisce il confine operativo del repository: quali input arrivano dall’utente, quali funzioni li trasformano, quali servizi vengono chiamati e quali dati possono uscire.

Nel caso di un possibile SSRF, il report dovrebbe chiarire almeno questi punti:

1. quali endpoint accettano URL, host, path o destinazioni di rete dal client;
2. se il valore viene validato prima della chiamata HTTP;
3. se i redirect possono portare verso una destinazione non verificata;
4. se il server può raggiungere IP privati, loopback o servizi di metadata;
5. se il codice riutilizza cookie, token o header privilegiati;
6. quali output del tool vengono passati al modello o registrati nei log;
7. se esistono percorsi alternativi con controlli più deboli;
8. se gli errori rivelano indirizzi interni, header o risposte sensibili.

Questo è il valore di un verdetto: non una lista astratta di buone pratiche, ma una conclusione collegata al comportamento del tuo repo. Se il problema è una route precisa, devi sapere quale route, quale funzione e quale evidenza rendono il confine insufficiente.

Con VibeInspect carichi lo ZIP del progetto e ricevi un PDF con un verdetto. Il piano Diagnostic è pensato proprio per un buco tecnico circoscritto: include file, riga ed evidenze. Non modifica il codice, non è un pentest e non promette che ogni rischio del mondo sia stato eliminato. Ti dà una base concreta per decidere il prossimo fix.

Cosa un linter non vede

Un linter può segnalare una chiamata a fetch, un URL costruito in modo sospetto o una gestione incompleta degli errori. Può trovare alcuni pattern pericolosi.

Non può però stabilire da solo se una destinazione è raggiungibile dal server, se un redirect aggira il controllo iniziale o se il risultato di una chiamata esterna viene trattato come semplice dato invece che come contenuto non attendibile.

Per rispondere servono più livelli del progetto:

• route HTTP;
• middleware di autenticazione;
• validazione dell’input;
• client HTTP;
• resolver DNS e gestione redirect;
• configurazione di rete;
• variabili d’ambiente;
• prompt e tool disponibili al modello;
• logging e gestione degli errori.

Un linter guarda soprattutto la riga. L’SSRF nasce dal collegamento tra la riga, il contesto di rete e l’autorità concessa al server.

Anche i test possono fallire il punto. Un test che usa https://example.com dimostra soltanto che il caso felice funziona. Servono casi negativi: URL localhost, indirizzi privati, redirect a una rete interna, schema non HTTP, risposta enorme, timeout e host che cambia risoluzione.

Inoltre, cifrare un payload non lo rende automaticamente sicuro. Il controllo deve restare attivo anche dopo ogni trasformazione e prima di ogni chiamata esterna. Il risultato di un tool va trattato come contenuto non attendibile, anche quando proviene da un componente che il sistema considera “interno”.

Cosa fare questa settimana

Scegli il flusso Replit che scarica URL, importa contenuti o usa un agente per chiamare servizi esterni. Poi:

• cerca fetch, client HTTP e proxy server-side;
• elenca tutte le destinazioni controllabili dall’utente o dal modello;
• blocca loopback, IP privati, metadata endpoint e redirect non verificati;
• consenti soltanto gli schemi e i domini necessari;
• imposta timeout, limiti di dimensione e numero di redirect;
• non inoltrare automaticamente cookie, token o header interni;
• separa istruzioni fidate e contenuto recuperato dal web;
• tratta ogni output di tool come non attendibile;
• verifica che i log non contengano risposte o credenziali sensibili;
• aggiungi test per destinazioni vietate e percorsi alternativi;
• fai emettere un verdetto sul repo prima del prossimo go-live.

Se hai costruito con Replit e il tuo prodotto usa fetch, scraping o agenti con accesso alla rete, carica il repo su VibeInspect. Per un possibile SSRF scegli Diagnostic: ti servono file, righe ed evidenze per capire dove il proxy supera il perimetro previsto e correggerlo.