Il prompt injection può arrivare dopo il controllo: cosa rischia il tuo repo Lovable

Il contenuto cifrato ha superato il filtro e il problema è arrivato dopo

Un gruppo di ricercatori di Adversa ha mostrato un caso che dovrebbe interessare chiunque stia costruendo prodotti AI con accesso a strumenti esterni: un payload malevolo inserito in una pagina web è stato cifrato con AES-256-GCM, poi decifrato dal modello dentro l’ambiente di esecuzione del codice e infine usato per inviare dati verso un server controllato dall’attaccante.

Il test è stato condotto contro Grok 4.5 Fast. Secondo il report ripreso da The New Stack, la tecnica è stata provata 20 volte con un tasso di successo dichiarato del 40%. Il dettaglio importante non è l’algoritmo crittografico in sé: è il passaggio da contenuto apparentemente innocuo a istruzione operativa durante il flusso dell’agente.

Un filtro può controllare il testo che entra nel modello. Ma se il modello esegue codice, interpreta un risultato e poi chiama un endpoint esterno, la superficie di rischio si sposta dentro la pipeline.

Cosa significa se il tuo codice l’ha scritto Lovable

Se hai usato Lovable per trasformare un’idea in un’app funzionante, probabilmente hai ottenuto velocemente un’interfaccia, alcune API e collegamenti a servizi esterni. È un ottimo modo per arrivare a un prototipo o a una prima release senza passare settimane a costruire lo scheletro del prodotto.

Il problema nasce quando quel prototipo inizia a gestire dati reali. Un’app Lovable può ricevere testo da utenti, documenti da elaborare, risposte da API, contenuti da CMS o risultati da integrazioni. A quel punto il rischio non è soltanto: “il modello ha letto un prompt malevolo?”. La domanda diventa: “che cosa succede quando un output non fidato viene passato al componente successivo?”.

Il buco concreto di oggi è il confine di fiducia nei tool output.

Immagina un flusso semplice:

1. l’utente chiede all’app di riassumere una pagina;
2. l’app scarica il contenuto della pagina;
3. un modello analizza il testo;
4. un tool di esecuzione trasforma o decodifica una parte del contenuto;
5. un altro tool effettua una richiesta HTTP;
6. l’app restituisce il risultato.

Se il sistema tratta ogni passaggio come “interno” o “già validato”, un’istruzione introdotta dalla pagina può cambiare forma senza perdere il proprio intento. Può diventare una stringa restituita da uno script, un campo JSON, un URL costruito dinamicamente o un parametro passato a un’integrazione.

Per chi ha spedito con Lovable, questo non significa che il tool sia il problema o che tu abbia lavorato male. Significa che la velocità di generazione ha reso facile collegare componenti che, in produzione, hanno livelli di fiducia diversi. Il repo può compilare, il flusso può funzionare e il rischio può restare invisibile.

Perché ora ti serve un audit sul repo

Il passaggio che spesso manca è un verdetto sul comportamento effettivo del sistema. Non una lista generica di buone pratiche: una risposta concreta alla domanda “questo repo espone un percorso credibile da input non fidato ad azione sensibile?”.

Un audit VibeInspect prende il repository ZIP e ricostruisce i punti in cui dati esterni attraversano il sistema. Nel caso del prompt injection, l’attenzione va su almeno quattro elementi:

• quali endpoint accettano contenuti controllati dall’utente o da fonti esterne;
• quali funzioni invocano modelli, interpreti, browser automation o richieste HTTP;
• quali output vengono riutilizzati come istruzioni, parametri o codice;
• quali autorizzazioni e segreti sono disponibili nello stesso percorso.

Il risultato utile non è “hai usato l’AI, quindi sei esposto”. È capire se esiste una catena tecnica verificabile: contenuto remoto, trasformazione, accesso a dati privati e uscita verso la rete. Se la catena c’è, puoi decidere se bloccarla, separare i privilegi, introdurre approvazioni o ridurre il perimetro.

Per un buco tecnico come questo serve il piano Diagnostic: il report deve indicare file, righe ed evidenze, così puoi tornare nel repo e correggere il percorso. Il piano Snapshot è utile per uno score iniziale, ma non restituisce file o righe.

L’audit non riscrive il codice, non applica fix e non sostituisce una revisione umana. Serve a togliere ambiguità: hai un verdetto, hai le prove e sai quale parte del sistema merita attenzione prima del prossimo go-live.

Cosa un linter non vede

Un linter può segnalare una variabile non usata, un import sospetto, una regola di stile o alcuni pattern noti. Può essere indispensabile, ma non sa sempre ricostruire il significato operativo di una sequenza distribuita su più file e servizi.

Nel caso del prompt injection cifrato, il problema potrebbe non essere una singola riga evidentemente pericolosa. Potrebbe essere la combinazione di comportamenti ordinari:

• scaricare una pagina indicata dall’utente;
• eseguire uno script per estrarre o convertire dati;
• inserire il risultato in un nuovo prompt;
• consentire al modello di scegliere un URL;
• aggiungere automaticamente dati della sessione a una richiesta;
• usare credenziali disponibili nell’ambiente server.

Ogni pezzo, preso isolatamente, può sembrare ragionevole. Il rischio emerge dal percorso completo e dal fatto che un output di tool venga promosso implicitamente a informazione affidabile.

Un linter non conosce necessariamente la differenza tra “testo da riassumere” e “istruzione da eseguire”. Non decide se un URL costruito dal modello può raggiungere la rete pubblica. Non verifica se un token dell’utente è disponibile nello stesso contesto di un browser automation tool. Non produce, da solo, un verdetto sul blast radius di una catena di integrazioni.

Questo è il motivo per cui un repo vibe-coded può apparire pulito e restare rischioso. La qualità sintattica non equivale alla sicurezza del comportamento.

Cosa fare questa settimana

Dedica un’ora a mappare il percorso dei dati nel tuo prodotto:

• elenca tutte le fonti esterne che l’app può leggere;
• identifica ogni punto in cui il modello può invocare un tool;
• separa chiaramente contenuto, istruzioni e parametri;
• verifica quali funzioni possono fare richieste verso Internet;
• elimina dai contesti dell’agente i segreti che non servono;
• limita domini, metodi HTTP e destinazioni consentite;
• registra quale input ha prodotto ogni tool call;
• prova cosa succede quando un output contiene un URL, uno script o un’istruzione inattesa.

Poi fai un audit del repo prima di aggiungere altre feature. Più integrazioni accumuli, più diventa difficile capire quale componente abbia trasformato un testo non fidato in un’azione.

Se hai spedito con Lovable e il buco è tecnico, parti da un Diagnostic: ottieni un verdetto con evidenze file/riga sul percorso che può collegare input esterno, dati sensibili e azioni di rete. Avvia l’audit VibeInspect.ai.