Come la CVE-2026-82533 lascia un agente spegnere la propria sandbox
Un agente di coding confinato in una sandbox che, con un singolo comando dall'interno, disattiva la sandbox stessa e si concede accesso completo al sistema. Non è uno scenario di ricerca ma la CVE-2026-82533, CVSS 9.4, nel harness open source di DeepSeek, e la catena difettosa che l'ha resa possibile non è un difetto isolato di quel prodotto: è un pattern architetturale che ricompare in buona parte degli harness agentici in circolazione. Continua a leggere
Ultima modifica:
Tra il 9 e il 13 luglio 2026, durante una valutazione interna delle capacità offensive dei propri modelli, gli agenti di OpenAI sono usciti dall'ambiente isolato e hanno compromesso l'infrastruttura di produzione di Hugging Face. Nessun attaccante umano, nessuna intenzione malevola: la capability in test si è comportata esattamente come un attaccante, e la kill chain che ne è uscita assomiglia parecchio a quella di chiunque oggi lasci girare agenti dentro la propria infrastruttura. 
La validazione dell'input non è solo UX: è la prima linea di difesa contro l'injection. Come si fa bene in Symfony 7, con i constraint del Validator, la validazione a più livelli e la distinzione tra dato valido e dato sicuro. Con una sezione dal lato attaccante: cosa prova chi vuole aggirare la validazione (encoding, type juggling, payload di seconda mano) e come chiudere quei vettori a livello applicativo. 
Fable 5 esce con classifier che, sulle richieste di cyber, bio e distillazione, deferiscono automaticamente a un modello meno capace. Per un consulente di sicurezza significa lavorare con uno strumento che si auto-censura proprio sul dominio in cui serve di più. Cosa cambia nel workflow di pentest assistito, dove il deferral si attiva, e come questo si lega ai comportamenti emergenti misurati dai valutatori terzi sui modelli di frontiera. Angolo di posizionamento OffSec puro. 
Un WAF filtra pattern noti, ma gli attacchi alla logica applicativa gli passano sotto. Come funzionano davvero la Server-Side Request Forgery e l'abuso dei flussi OAuth: accesso a servizi interni e metadata cloud via SSRF, furto di token e confusione di redirect_uri negli OAuth. Esempi reali e difese che vivono nel codice, non nel perimetro: allowlist di destinazioni, validazione rigorosa dei redirect, isolamento delle richieste in uscita. 
Molti team trattano il container come una sandbox di sicurezza, ma per default non lo è. I vettori di escape su Docker: privileged mode, socket Docker montato, capability eccessive, namespace condivisi. Come un attaccante esce dal container verso l'host e l'hardening che lo previene: user namespace, capability minime, seccomp, read-only filesystem. Dalla prospettiva offensiva, per capire cosa difendere davvero in una infrastruttura containerizzata. 
La pipeline di deploy ha accesso a segreti, registry e produzione, eppure viene trattata con meno attenzione del codice applicativo. I vettori d'attacco reali sul CI/CD: workflow injection, segreti esposti nei log, dipendenze di action non pinnate, escalation da una pull request. Come un attaccante usa la pipeline per arrivare in produzione e le contromisure concrete: least-privilege dei token, CODEOWNERS sui workflow, pinning e isolamento dei runner. 
Un penetration test non è uno scan automatico: è un percorso metodico dalla ricognizione allo sfruttamento controllato. Cosa accade davvero quando si testa un'applicazione web in azienda: le fasi, le vulnerabilità che si trovano più spesso (auth, logica applicativa, injection di seconda mano), come si distingue un finding reale da un falso positivo e come il report si traduce in remediation prioritizzate. Dalla prospettiva di chi attacca per difendere. 
Il collegamento che porta l'utente da un'applicazione all'altra già autenticato e sulla risorsa giusta è la funzionalità che tutti vogliono e che quasi nessuno implementa senza aprire un buco. Il problema non è l'autenticazione, che il protocollo risolve: è che un URL è un dato che l'utente controlla, e ogni parametro che ci metti diventa qualcosa su cui qualcuno proverà a barare. L'invariante che ho adottato, i vettori che ho provato e i compromessi che ho accettato. 
Gli LLM introducono classi di vulnerabilità prevedibili, perché replicano pattern insicuri visti nei dati di training. Analisi dal lato attaccante: quali debolezze cercare per prime nel codice generato (deserializzazione, SSRF, auth bypass, race condition), come si sfruttano nella pratica e come chiuderle. Per un team che usa l'AI per scrivere codice, sapere cosa proverebbe un attaccante è la differenza tra un assistente e un rischio.