Titelkarte mit der Aufschrift „133 Agenten, ein Django-CVE“ über dem Label „Mistral Large 4 · Le Chonk“, mit Chips für „133 Agenten“, „90x-Wiedergabe“ und „0 genannte CVEs“, einem 133-Punkte-Raster mit einem hervorgehobenen Agenten und einer Fußzeile, die darauf hinweist, dass Django am 3. November sechs CVE-Fixes veröffentlichte: einen mittelschweren, fünf niedrige und keinen kritischen.
Engineering & Research

Die 133-Agenten-Django-Demo von Mistral Large 4: Sie reproduzierte einen Fehler, den Django bereits behoben hatte

Autor

Rowan Sterling

Veröffentlicht am

Neueste Modelle · 20Alle Modelle ansehen →
Benchmarks: Artificial Analysis · täglich aktualisiert
Zurück zu allen Beiträgen

Mistral Large 4, das Open-Weight-Modell mit 1,05 Billionen Parametern, dem Mistral AI den Spitznamen Le Chonk gegeben hat, wurde am 4. November 2026 als End-to-End-Sicherheitsforscher vorgestellt. Ein Beitrag vom offiziellen X-Konto von Mistral fragte, ob das Modell „eine kritische Schwachstelle finden, sie nachweisen und beheben“ könne, und antwortete dann mit 133 Agenten, einer Django-Codebasis und einem 90×-Zeitraffer. Der Beitrag nennt keine CVE. Er veröffentlicht keinen Patch. Er nennt weder eine Laufzeit noch eine Tokenanzahl noch die Anzahl falsch positiver Ergebnisse noch einen Link zu einer technischen Ausarbeitung.

Die zeitliche Einordnung grenzt den Kreis der Möglichkeiten ein. Das Sicherheitsteam von Django hatte am Vortag, dem 3. November 2026, Fixes für sechs CVEs in 6.1.3, 6.0.10 und 5.2.19 veröffentlicht (für ein Problem ist kein 5.2-Patch aufgeführt). Wenn dieses Paket das Ziel war – und es ist das einzige Django-CVE-Paket in den Nachrichten jener Woche –, kann die Demo keine unbekannte Schwachstelle entdeckt haben, denn alle sechs waren öffentlich und gepatcht, bevor das Video veröffentlicht wurde. Es handelte sich auch nicht um eine kritische Schwachstelle. Eine trug eine mittlere Einstufung; die anderen fünf wurden als niedrig eingestuft.

Das macht die Demo nicht wertlos. Es macht sie zu einer Workflow-Demonstration statt zu einer Entdeckungsbehauptung, und der Unterschied ist wichtig für alle, die entscheiden, ob ein Open-Weight-Modell einen Platz in der Triage-Warteschlange eines Sicherheitsteams einnehmen kann.

Was Mistral tatsächlich gezeigt hat

Der Post ist kurz: „Kann Mistral Large 4 eine kritische Schwachstelle finden, sie nachweisen und beheben? Wir haben es an einem aktuellen Django-CVE getestet. 133 Agenten kartieren den Code, suchen nach Fehlern, testen Angriffsszenarien und bestätigen den Bug. Dann patcht Le Chonk ihn. Triage, Repro, Patch. Mit 90-facher Geschwindigkeit gezeigt.“ Zum Zeitpunkt des Verfassens hatte er 540 Likes, 94 Reposts, 107 Antworten und etwa 21.000 Aufrufe – ein ordentlicher Produktbeitrag, keine Offenlegung.

Mistrals eigene Release Notes beschreiben denselben Workflow ausführlicher. Die Open-Weight-Ankündigung nennt einen Agenten für „Cyber Vulnerability Triage“, der eingehende Schwachstellenberichte liest, die Fehler in einer isolierten Sandbox reproduziert, einen Patch schreibt und iteriert und damit fortfährt, „bis ein Canary-Exploit nicht mehr funktioniert“. Das ist eine dokumentierte Eigenschaft des Modells, die bereits vor dem Video beschrieben wurde. Der Lauf mit 133 Agenten ist eine öffentliche Demonstration davon.

Die Angabe 90× ist eine Wiedergabegeschwindigkeit, kein Ergebnis. Ohne die Länge des Quellvideos oder die reale Laufzeit des Durchlaufs lässt sie sich nicht in eine Dauer umrechnen. Ein 90×-Zeitraffer eines zwei Stunden dauernden Durchlaufs und ein 90×-Zeitraffer eines zwei Tage dauernden Durchlaufs sehen auf einer Zeitleiste identisch aus.

Der Django-Batch und warum „kritisch“ nicht passt

Djangos Sicherheitsmitteilung vom 3. November ist ungewöhnlich konkret, genau das macht sie als Kontrolle nützlich. Sie führt sechs Probleme auf, jeweils mit einer CVE, einem Melder, einer betroffenen Branch-Gruppe und einem Fix-Commit. Die Schweregrade sind nicht annähernd kritisch:

• CVE-2026-111362 — mittelschwer. Ein crs-Member einer GeoJSON-Geometrie konnte GDAL dazu veranlassen, während der Validierung, beim Speichern oder Abfragen Netzwerkanfragen zu stellen oder lokale Dateien zu lesen: ein SSRF- und Local-File-Read-Pfad.

• CVE-2026-108147 — niedrig. Base64-kodierte Multipart-Uploads wurden gepuffert, bevor die Upload-Handler ausgeführt wurden, wodurch FILE_UPLOAD_MAX_MEMORY_SIZE umgangen und eine Speichererschöpfung ermöglicht wurde.

• CVE-2026-111211 — niedrig. Steuerzeichen in ungültigen Werten von Geometrieformularen wurden ohne Escaping protokolliert, was Log-Injection oder -Fälschung ermöglichte.

• CVE-2026-113593 — niedrig. Fehlende und leere Vary-Header-Werte erzeugten denselben Cache-Schlüssel, wodurch private zwischengespeicherte Antworten möglicherweise offengelegt werden.

• CVE-2026-113733 — niedrig. Admin-Benutzer mit Nur-Lese-Zugriff konnten vollständige Passwort-Hashes für bestimmte benutzerdefinierte Benutzermodelle einsehen.

• CVE-2026-114582 — niedrig. Eingaben als SpatialReference-Zeichenfolge könnten GDAL-URL-Abrufe oder Dateilesevorgänge auslösen; vollständiger Schutz erfordert GDAL 3.9 oder höher.

Alle sechs wurden am selben Tag behoben. Das ist der normale Django-Prozess: Der Sicherheitshinweis, die Patches und die CVE-Einträge erscheinen zusammen. Ein Modell, das den Fehler einen Tag später „bestätigt“, bestätigt einen Fehler, dessen Fix bereits im Repository ist und dessen Reproduktionsschritte im öffentlichen Bericht stehen. Einen gemeldeten Fehler zu reproduzieren ist die erste Aufgabe einer Triage-Warteschlange, also ist das echte Arbeit – aber es ist nicht dasselbe wie einen zu finden.

Mistral hat die CVE nicht benannt, daher lässt sich die Behauptung nicht gegen einen konkreten Sicherheitshinweis prüfen. Wenn das Ziel außerhalb des November-Batches lag, bietet der Beitrag keine Möglichkeit, es zu identifizieren, zu datieren oder den generierten Patch mit dem Upstream-Fix zu vergleichen. Der Patch selbst wurde nicht veröffentlicht.

Screenshot of the Django 3 November 2026 security release page showing the 6.1.3, 6.0.10 and 5.2.19 releases, CVE-2026-108147 and CVE-2026-111211 labelled low severity, and CVE-2026-111362 labelled moderate.

133 Agenten ist eine Orchestrierungsnummer.

Agentenanzahl ist eine Designentscheidung, kein Punktestand. Eine Pipeline kann 133 Agenten verwenden, weil sie je Datei einen, je Hypothese einen oder je Angriffspfad einen auffächert; dieselbe Arbeit lässt sich mit fünf Agenten und mehr Turns erledigen. Was sich mit der Anzahl ändert, sind Kosten, Latenz und die Zahl unabhängiger Versuche – nicht die Fähigkeit des Modells pro Token.

Es fehlen genau die Kennzahlen, die die Anzahl aussagekräftig machen würden: wie viele mögliche Fehler gemeldet wurden, wie viele davon falsch positiv waren, wie viele Agenten pro bestätigtem Fehler nötig waren und was der Lauf an Tokens gekostet hat. Ein System, das 200 Kandidaten meldet, um einen echten Fehler zu bestätigen, ist ein anderes Produkt als eines, das drei meldet und einen bestätigt, und beide können ehrlicherweise als „{{1}}133 Agenten.{{/1}}“ beschrieben werden.

Mistrals veröffentlichte Beschreibung legt eher eine eng begrenzte, überprüfbare Schleife nahe als eine ergebnisoffene Entdeckung: in einer Sandbox reproduzieren, an einem Patch iterieren, aufhören, wenn der Canary-Exploit fehlschlägt. Genau diese Schleife zeigt die Django-Demo. Es ist eine gute Schleife. Es ist auch die Schleife, die ein menschlicher Triager mit einem Debugger und einer Testsuite durchläuft.

Die Sicherheitskennzahlen, die Mistral tatsächlich veröffentlicht

Mistrals Open-Weight-Beitrag führt Mistral Large 4 im Artificial Analysis Cyber Index mit 51 % auf, in einer vom Anbieter erstellten Grafik, die MiMo-V2.6-Pro bei 56 % und DeepSeek-V4.1-Flash 1017 bei 57 % platziert, mit Kimi K3 bei 41 % und GLM-5.3 bei 36 %. Der Index prüft, ob ein Modell Schwachstellen in einer Codebasis entdecken, reproduzieren und validieren sowie patchen kann – dieselben drei Verben wie in der Demo.

Derselbe Beitrag meldet eine durchschnittliche Ablehnungsrate von 96,6 % bei bösartigen Cyber-Anfragen, die Mistral als den höchsten Wert bezeichnet, den es unter offenen Modellen misst, sowie eine Angriffsresistenz von 97,1 % im B3-Agent-Sicherheitsbenchmark, gegenüber 93,3 % in der Vorschau. Die Vorschauseite vom Oktober nannte außerdem einen Wert von 82 % bei Mistrals eigenem Test zur Reproduktion und Behebung von Schwachstellen und 93 % von 40 Cybench-Herausforderungen; der Open-Weight-Beitrag wiederholt keine der beiden Angaben.

Alle diese Angaben stammen von Anbietern. Keine davon wurde unabhängig reproduziert, und das Cyber-Index-Diagramm ist Mistrals Darstellung eines Drittanbieter-Index und keine Aufzeichnung eines Leaderboards. Das macht die Zahlen nicht falsch. Es macht sie zu Behauptungen, und das Demo-Video ist eine weitere Behauptung in derselben Reihe.

In der Positionierung liegt eine echte Spannung. Ein Modell, das darauf abgestimmt ist, 96,6 % bösartiger Cyber-Anfragen abzulehnen, wird zugleich mit seiner Fähigkeit beworben, Exploits nachzubauen und Patches zu schreiben. Mistrals Antwort ist eine spezialisierte Variante für Penetrationstests und Red-Teaming, die erst nach Prüfung und nur mit vertraglichen Beschränkungen auf eigene oder autorisierte Systeme zugänglich ist. Der Open-Weight-Checkpoint ist das allgemeine Modell, mit Guardrails, die der Host anpassen kann — genau deshalb folgt die Dual-Use-Frage den Gewichten statt der API.

Screenshot of the Mistral Large 4 model card on Hugging Face showing the Le Chonk title, 1 trillion total and 49 billion active parameters, a 1M-token context, text-and-image input, the NVFP4 checkpoint note and evaluation results including Terminal-Bench at 41.

Was würde aus der Demo einen Beweis machen?

Eine glaubwürdige End-to-End-Behauptung braucht sechs Dinge. Keines davon ist exotisch; alle fehlen in dem Beitrag.

• Eine benannte CVE oder ein Fehler ohne öffentlichen Bericht – damit ein Leser Entdeckung von Reproduktion unterscheiden kann.

• Den anfälligen Commit und den gepatchten Commit, damit der Diff überprüft werden kann.

• Eine Vorher-Nachher-Reproduktion in derselben Umgebung, einschließlich des fehlschlagenden und des erfolgreichen Exploits.

• Die Anzahl der Falsch-Positiven: wie viele Kandidaten die Agenten erzeugten, bevor einer übrig blieb.

• Tatsächliche Laufzeit (Wall-Clock-Zeit) und Token-Kosten für den gesamten Durchlauf, nicht ein Wiedergabe-Multiplikator.

• Ein unabhängiger erneuter Durchlauf von jemandem, der nicht Mistral ist.

Veröffentlichen Sie diese, und das Argument ändert sich. Bis dahin lautet die ehrliche Beschreibung: „Mistral hat seinen Triage-Agenten an einem öffentlichen Django-Bug vorgeführt“, was eine nützliche Produktdemo und eine deutlich kleinere Behauptung ist als der erste Satz des Beitrags.

Generated card titled 'What the post claims vs what it proves', with six rows contrasting claims such as finding a vulnerability and critical severity against the published evidence, and a verdict strip reading 'a workflow demo, not evidence of discovery'.

Das Muster auf die eigene Codebasis anwenden

Die offenen Gewichte sind der Teil, der für Sicherheitsteams zählt. Mistral veröffentlichte den Checkpoint am 29. Oktober 2026 unter der Mistral Ecosystem Open-Weight License, einer modifizierten MIT-Lizenz, die Nutzung, Modifikation, Fine-Tuning und Kommerzialisierung erlaubt, aber für alle, die ein Model-as-a-Service-Geschäft betreiben, eine separate Lizenz verlangt. Der Checkpoint hat 1,05 Billionen Parameter bei 49 Milliarden aktiven pro Token, einen Kontext von 1 Mio. Token und eine NVFP4-Variante für Blackwell-GPUs. Das Selbst-Hosting ist ein Cluster-Kauf, kein Laptop-Download, aber es hält Quellcode und Ergebnisse innerhalb Ihres Perimeters — der Grund, warum ein Sicherheitsteam es einer API vorziehen würde.

Der Workflow ist portabler als das Modell: den Code kartieren, Kandidaten-Schwachstellen erzeugen, den Angriff simulieren, in einer Sandbox reproduzieren, patchen und dann verifizieren, dass der Exploit nicht mehr ausgelöst wird. Der schwache Schritt in jeder Implementierung ist der Verifier. Dasselbe Modell, das den Patch geschrieben hat, ist ein schlechter Richter darüber; ein zweites Modell aus einer anderen Familie erkennt, wenn man ihm den Diff und die Reproduktion gibt, einen relevanten Anteil schlechter Patches, die das erste Modell verteidigen wird.

Hier hilft Routing. Mistral Large 4 ist nicht im Katalog von OrcaRouter enthalten – es wird über Mistrals eigene API bereitgestellt und ist für Self-Hosting herunterladbar –, doch OrcaRouter bringt über 200 andere Modelle hinter einem einzigen OpenAI-kompatiblen Schlüssel mit 0 % Aufschlag auf den Listenpreis des Anbieters, automatischem Failover und einer Routing-DSL, die einen Verifier für eine zweite Meinung in denselben Aufruf einbinden kann. Eine Triage-Pipeline braucht kein Modell, das in allem gut ist; sie braucht einen Patch-Schreiber und einen Patch-Reviewer, die sich unterscheiden, und ein einziger Schlüssel ist ein günstigerer Weg dorthin als zwei Anbieterverträge.

Die Behauptung, die es zu beobachten gilt

Mistral hat die Bestandteile eines glaubwürdigen Sicherheitsprodukts: offene Gewichte, eine dokumentierte Triage-Schleife, starke Ablehnungsmetriken und einen Benchmark, der die richtigen Verben misst. Was ihm öffentlich fehlt, ist ein Fall, in dem das Modell etwas gefunden hat, das noch nicht behoben war. Die nächste Demo sollte den Bug benennen, den Diff veröffentlichen und jemand anderen ihn ausführen lassen. Bis dahin ist das Video mit den 133 Agenten eine Demonstration von Orchestrierung, kein Beleg für Entdeckung – und das Wort „kritisch“ leistet mehr, als der Django-Batch hergibt.