La demo Django con 133 agenti di Mistral Large 4: ha riprodotto un bug che Django aveva già corretto

Mistral Large 4, il modello open-weight da 1,05 trilioni di parametri che Mistral AI ha soprannominato Le Chonk, è stato presentato il 4 novembre 2026 come ricercatore di sicurezza end-to-end. Un post dall'account X ufficiale di Mistral ha chiesto se il modello potesse "trovare una vulnerabilità critica, dimostrarla e correggerla", per poi rispondere con 133 agenti, una codebase Django e un time-lapse a 90×. Il post non nomina alcun CVE. Non pubblica alcuna patch. Non fornisce runtime, conteggio dei token, conteggio dei falsi positivi né link a una documentazione tecnica.

La tempistica restringe il campo. Il team di sicurezza di Django aveva rilasciato correzioni per sei CVE il giorno precedente, il 3 novembre 2026, nelle versioni 6.1.3, 6.0.10 e 5.2.19 (per un problema non è elencata alcuna patch per la 5.2). Se quel lotto era l'obiettivo — ed è l'unico lotto di CVE di Django nelle notizie quella settimana — la demo non può aver scoperto un difetto sconosciuto, perché tutti e sei erano pubblici e corretti prima che il video fosse pubblicato. Non era inoltre una vulnerabilità critica. Uno presentava una valutazione moderata; gli altri cinque erano valutati come bassi.

Ciò non rende la demo priva di valore. La rende una dimostrazione di flusso di lavoro anziché un'affermazione di scoperta, e la distinzione conta per chiunque debba decidere se un modello open-weight possa trovare posto nella coda di triage di un team di sicurezza.

Cosa ha effettivamente mostrato Mistral

Il post è breve: "Mistral Large 4 può trovare una vulnerabilità critica, dimostrarla e correggerla? L'abbiamo testato su una recente CVE di Django. 133 agenti mappano il codice, cercano falle, testano scenari di attacco e confermano il bug. Poi Le Chonk la corregge. Triage, riproduzione, patch. Mostrato a velocità 90x." Al momento della stesura aveva 540 like, 94 repost, 107 risposte e circa 21.000 visualizzazioni — un post di prodotto di tutto rispetto, non una divulgazione.

Le note di rilascio di Mistral descrivono lo stesso flusso di lavoro in modo più dettagliato. L'annuncio open-weight elenca un agente "Cyber Vulnerability Triage" che legge i report di vulnerabilità in arrivo, riproduce i difetti in una sandbox isolata, scrive una patch e itera su di essa, e continua «finché un exploit canary non funziona più». Si tratta di una funzionalità documentata del modello, descritta prima del video. L'esecuzione con 133 agenti è una dimostrazione pubblica di ciò.

Il valore 90× è una velocità di riproduzione, non un risultato. Senza la durata del video di origine o il tempo reale dell'esecuzione, non può essere convertito in una durata. Un time-lapse 90× di un'esecuzione di due ore e un time-lapse 90× di un'esecuzione di due giorni sono identici su una timeline.

Il batch Django, e perché "critical" non è adatto

L'avviso di Django del 3 novembre è insolitamente dettagliato, ed è proprio questo a renderlo utile come controllo. Elenca sei problemi, ciascuno con un CVE, un segnalatore, un insieme di branch interessati e un commit di correzione. Le gravità non sono affatto vicine a quelle critiche:

• CVE-2026-111362 — moderata. Il membro crs di una geometria GeoJSON potrebbe indurre GDAL a effettuare richieste di rete o a leggere file locali durante la validazione, il salvataggio o l'interrogazione: un percorso di SSRF e di lettura di file locali.

• CVE-2026-108147 — bassa. I caricamenti multipart codificati in Base64 venivano bufferizzati prima dell'esecuzione dei gestori di caricamento, aggirando FILE_UPLOAD_MAX_MEMORY_SIZE e consentendo l'esaurimento della memoria.

• CVE-2026-111211 — bassa. Caratteri di controllo presenti in valori non validi del modulo di geometria venivano registrati nei log senza escaping, consentendo l'iniezione o la falsificazione dei log.

• CVE-2026-113593 — basso. Valori mancanti e vuoti dell'intestazione Vary producevano la stessa chiave di cache, con il rischio di esporre risposte private memorizzate nella cache.

• CVE-2026-113733 — bassa. Gli utenti amministratori con accesso in sola visualizzazione potevano vedere gli hash completi delle password per determinati modelli utente personalizzati.

• CVE-2026-114582 — basso. L'input di tipo stringa SpatialReference potrebbe attivare recuperi di URL o letture di file da parte di GDAL; la protezione completa richiede GDAL 3.9 o versione successiva.

Tutti e sei sono stati corretti lo stesso giorno. È il normale processo di Django: l'avviso, le patch e i record CVE arrivano insieme. Un modello che "conferma il bug" un giorno dopo sta confermando un bug la cui correzione è già nel repository e i cui passaggi di riproduzione sono nel report pubblico. Riprodurre un bug segnalato è il primo compito di una coda di triage, quindi si tratta di lavoro vero — ma non è la stessa cosa che trovarne uno.

Mistral non ha indicato il CVE, quindi non è possibile verificare l'affermazione rispetto a un avviso specifico. Se il target era al di fuori del lotto di novembre, il post non offre alcun modo per identificarlo, datarlo o confrontare la patch generata con la correzione upstream. La patch stessa non è stata pubblicata.

133 agenti è un numero di orchestrazione

Il numero di agenti è una scelta di progettazione, non un punteggio. Una pipeline può usare 133 agenti perché ne distribuisce uno per file, uno per ipotesi o uno per percorso di attacco; lo stesso lavoro può essere svolto con cinque agenti e più turni. Ciò che cambia con il numero è il costo, la latenza e il numero di tentativi indipendenti — non la capacità del modello per token.

Le metriche che renderebbero significativo il conteggio sono quelle mancanti: quanti potenziali difetti sono stati segnalati, quanti erano falsi positivi, quanti agenti sono stati necessari per ogni bug confermato e quanto è costata l'esecuzione in token. Un sistema che propone 200 candidati per confermare un vero bug è un prodotto diverso da uno che ne propone tre e ne conferma uno, ed entrambi possono essere onestamente descritti come "133 agenti".

La descrizione pubblicata da Mistral suggerisce un ciclo ristretto e verificabile anziché una scoperta aperta: riprodurre in una sandbox, iterare su una patch, fermarsi quando l'exploit canary fallisce. Quel ciclo è esattamente ciò che mostra la demo di Django. È un buon ciclo. È anche il ciclo che un triager umano esegue con un debugger e una suite di test.

I numeri sulla sicurezza che Mistral pubblica

{{1}}Il post open-weight di Mistral{{/1}} colloca {{2}}Mistral Large 4{{/2}} al 51% sull'{{3}}Artificial Analysis Cyber Index{{/3}}, in un {{4}}grafico prodotto dal fornitore{{/4}} che pone {{5}}MiMo-V2.6-Pro{{/5}} al 56% e {{6}}DeepSeek-V4.1-Flash 1017{{/6}} al 57%, con {{7}}Kimi K3{{/7}} al 41% e {{8}}GLM-5.3{{/8}} al 36%. L'indice verifica se un modello è in grado di {{9}}scoprire vulnerabilità{{/9}} in una codebase, {{10}}riprodurle e convalidarle{{/10}}, e {{11}}correggerle{{/11}} — gli stessi tre verbi della demo.

Lo stesso post riporta un tasso medio di rifiuto del 96,6% sulle richieste informatiche dannose, che Mistral definisce il più alto misurato tra i modelli aperti, e una resistenza agli attacchi del 97,1% sul benchmark B3 di sicurezza degli agenti, in aumento dal 93,3% dell’anteprima. La pagina di anteprima di ottobre indicava inoltre un punteggio dell’82% sul test interno di Mistral di riproduzione e correzione delle vulnerabilità e il 93% delle 40 sfide Cybench; il post open-weight non ripete nessuno dei due dati.

Tutti questi dati sono dichiarati dal fornitore. Nessuno è stato riprodotto in modo indipendente, e il grafico Cyber Index è una rappresentazione di Mistral di un indice di terze parti, non la cattura di una classifica. Questo non rende i numeri sbagliati. Li rende affermazioni, e il video dimostrativo è un'altra affermazione della stessa serie.

C’è una vera tensione nel posizionamento. Un modello addestrato a rifiutare il 96,6% delle richieste informatiche malevole viene anche venduto per la sua capacità di riprodurre exploit e scrivere patch. La risposta di Mistral è una variante specializzata per penetration testing e red-teaming, subordinata a verifiche e a limiti contrattuali ai sistemi di proprietà o autorizzati. Il checkpoint open-weight è il modello generale, con guardrail che l’host può regolare — ed è proprio per questo che la questione del duplice uso segue i pesi anziché l’API.

Cosa trasformerebbe la demo in una prova

Una rivendicazione end-to-end credibile richiede sei elementi. Nessuno di essi è esotico; tutti mancano dal post.

• Un CVE specifico, o un bug senza report pubblico — così il lettore può distinguere la scoperta dalla riproduzione.

• Il commit vulnerabile e il commit con la patch, così che il diff possa essere esaminato.

• Una riproduzione prima e dopo nello stesso ambiente, incluso l'exploit non riuscito e quello riuscito.

• Il conteggio dei falsi positivi: quanti candidati hanno avanzato gli agenti prima che uno superasse la selezione.

• Tempo reale e costo in token per l'intera esecuzione, non un moltiplicatore di riproduzione.

• Una nuova esecuzione indipendente da parte di qualcuno che non è Mistral.

Pubblicali e l'argomentazione cambia. Fino ad allora, la descrizione onesta è «Mistral ha dimostrato il suo agente di triage su un bug pubblico di Django», che è un'utile demo di prodotto e un'affermazione molto più modesta della prima frase del post.

Eseguire il pattern sul proprio codebase

I pesi aperti sono l'elemento che conta per i team di sicurezza. Mistral ha rilasciato il checkpoint il 29 ottobre 2026 con la Mistral Ecosystem Open-Weight License, una licenza MIT modificata che consente uso, modifica, fine-tuning e commercializzazione, ma richiede una licenza separata per chiunque gestisca un'attività di model-as-a-service. Il checkpoint ha 1,05 trilioni di parametri con 49 miliardi attivi per token, una finestra di contesto da 1 milione di token e una variante NVFP4 per GPU Blackwell. L'hosting autonomo è un acquisto di cluster, non un download su laptop, ma mantiene codice sorgente e risultati all'interno del proprio perimetro: il motivo per cui un team di sicurezza lo sceglierebbe rispetto a un'API.

Il flusso di lavoro è più portabile del modello: mappa il codice, genera difetti candidati, simula l'attacco, riproduce in una sandbox, applica la patch, poi verifica che l'exploit non si attivi più. Il passo debole in ogni implementazione è il verificatore. Lo stesso modello che ha scritto la patch è un pessimo giudice della stessa; un secondo modello di una famiglia diversa, a cui vengono forniti il diff e la riproduzione, intercetta una quota significativa di patch difettose che il primo modello difenderà.

È qui che il routing aiuta. Mistral Large 4 non è nel catalogo di OrcaRouter — viene servito tramite l'API di Mistral stessa ed è scaricabile per il self-hosting — ma OrcaRouter metteoltre 200 altri modelli dietro un'unica chiave compatibile con OpenAI con markup dello 0% sul prezzo di listino del provider, failover automatico e un DSL di routing che può comporre un verificatore di seconda opinione nella stessa chiamata. Una pipeline di triage non ha bisogno che un solo modello sia bravo in tutto; ha bisogno che lo scrittore della patch e il revisore della patch siano diversi, e un'unica chiave è un modo più economico per arrivarci rispetto a due contratti con i fornitori.

Il claim da tenere d'occhio

Mistral ha i pezzi di un prodotto di sicurezza credibile: pesi aperti, un ciclo di triage documentato, solide metriche di rifiuto e un benchmark che misura i verbi giusti. Ciò che non ha, in pubblico, è un caso in cui il modello abbia trovato qualcosa che non fosse già stato corretto. La prossima demo dovrebbe indicare il bug, pubblicare il diff e lasciare che qualcun altro lo esegua. Fino ad allora, il video dei 133 agenti è una dimostrazione di orchestrazione, non prova di scoperta — e la parola "critica" sta facendo più lavoro di quanto il batch Django supporti.