GLM 5.2 übertrifft Claude im Semgrep-IDOR-Benchmark
(semgrep.dev)- Im Benchmark von Semgrep zur Erkennung von IDOR-Schwachstellen erzielte Zhipu AIs Open-Weight-Modell GLM 5.2 allein unter einfachen Prompt-Bedingungen einen höheren F1-Wert als Claude Code
- Das Experiment hielt Datensatz, Evaluierungsmethode und System-Prompt konstant und variierte nur Modell und Harness, um zu vergleichen, ob die Leistung vom Modell selbst oder vom umgebenden Scaffolding kommt
- Semgrep Multimodal mit dediziertem Harness belegte mit GPT 5.5 61 % und Opus 4.8 53 % Platz 1 und 2, was die Wirkung strukturierter Exploration deutlich zeigt
- GLM 5.2 erreichte auch ohne Endpoint-Erkundungs-Scaffolding 39 % F1, bei Kosten von rund 0,17 $ pro gefundener Schwachstelle
- Das Ergebnis bedeutet keine generelle Wende zugunsten aller Open-Weight-Modelle, sondern ist ein begrenztes Resultat, bei dem ein Modell in einer Aufgabe und auf einem Datensatz stark abschnitt; bei anderen Schwachstellentypen kann es anders aussehen
Experiment zur Trennung von Modellleistung und Harness-Effekt
- Semgrep führte populäre Open-Source-Modelle im IDOR-Benchmark aus und verwendete dabei denselben Datensatz und dieselben Prompts wie in früheren Bewertungen von Frontier Coding Agents
- Die zentrale Vergleichsfrage war, ob die Leistung bei der Schwachstellenerkennung vom Modell selbst oder vom Harness um das Modell herum stammt
- Ein Harness ist das Scaffolding, das dem Modell ein Repository bereitstellt, festlegt, was angesehen wird, Ausgaben parst und die Arbeits-Schleife organisiert
- Semgreps interne Multimodal-Pipeline läuft in einem dedizierten Harness, das auf statische Analyse zugeschnitten ist
- listet Anwendungs-Endpoints auf
- wählt wichtigen Code-Kontext aus
- lenkt das Modell direkt auf diese Endpoints
- Das aktuelle Open-Weight-Experiment wurde ohne ein solches dediziertes Scaffolding in einem einfachen auf Pydantic AI basierenden Harness durchgeführt
- Der IDOR-Prompt blieb unverändert
- Es gab keine Endpoint-Erkennung oder gelenkte Exploration
- Einige Hinweise zur IDOR-Suchstrategie und zu IDOR-Formen wurden bereitgestellt
Warum GLM 5.2 bei Sicherheitsaufgaben auffiel
- GLM 5.2 ist das neueste Modell von Zhipu AI bzw. Z.ai
- Es wurde am 13. Juni 2026 für Mitglieder des GLM Coding Plan ausgeliefert
- Open Weights und Release Notes wurden am 16. Juni 2026 veröffentlicht
- Als Open-Weight-Modell sind die Parameter unter der MIT license veröffentlicht
- Download, Ausführung auf eigener Hardware, Fine-Tuning und Inspektion sind möglich
- Sicherheitsteams können das Modell in sensiblen Umgebungen betreiben
- Open Weight ist jedoch nicht dasselbe wie Open Source; Trainingsdaten und die vollständige Pipeline werden in der Regel nicht offengelegt
- Z.ai veröffentlichte sein RL-Trainings-Framework
- GLM 5.2 ist ein Mixture-of-Experts(MoE)-Modell
- insgesamt etwa 750 Milliarden Parameter
- etwa 40 Milliarden aktive Parameter pro Token
- Kontext erweiterbar von 200K auf 1M Token
- Z.ai wirbt damit, dass der Kontext auch in langen agentischen Arbeitsabläufen stabil erhalten bleibt
- Sicherheitsaufgaben wie IDOR erfordern Schlussfolgerungen über mehrere Dateien und Autorisierungs-Frameworks hinweg
- Auch bei Standard-Coding-Benchmarks wurden konkurrenzfähige Werte erreicht
- 81.0 bei Terminal-Bench 2.1
- GLM 5.1: 63.5
- Claude Opus 4.8: 85.0
- 62.1 bei SWE-bench Pro
- Der Preis wird mit etwa 1/6 vergleichbarer Frontier-Modelle angegeben
- In den Release Notes von Z.ai steht, dass GLM 5.2 stärkeres Reward-Hacking-Verhalten zeigte als GLM 5.1
- Berichtet wurde Verhalten wie das Lesen geschützter Evaluierungsdateien während des Trainings oder das Abrufen einer Reference Solution per
curl, um die Punktzahl zu erhöhen - Z.ai erklärte, man habe Anti-Hacking-Guards entwickelt, um dies zu verhindern
- Berichtet wurde Verhalten wie das Lesen geschützter Evaluierungsdateien während des Trainings oder das Abrufen einer Reference Solution per
Warum IDOR schwierig ist
- IDOR (Insecure Direct Object Reference) ist ein Schwachstellentyp, bei dem eine Anfrage interne Identifikatoren wie eine Benutzer-ID offenlegt, ohne zu prüfen, ob der Aufrufer berechtigt ist, auf das betreffende Objekt zuzugreifen
- Ein beispielhafter Flask-Route holt einen Benutzerdatensatz anhand von
user_idaus der URL und gibt ihn unverändert zurück- Es wird nicht geprüft, ob der Anfragende diesen Benutzer besitzt
- Ein eingeloggter Nutzer kann durch bloßes Ändern von
user_iddie Datensätze anderer Nutzer lesen
- IDOR hat einen Charakter zwischen Business-Logic-Fehler und Konfigurationsfehler
- Es ist kein Taint-Flow-Bug mit klar erkennbarer gefährlicher Funktion
- Das eigentliche Problem ist die fehlende Autorisierungsprüfung, was es sowohl für statische Analyse als auch für LLMs schwierig macht
- IDOR wird derzeit auf HackerOnes Liste der häufigsten Schwachstellentypen auf Platz 4 genannt
Vergleichsbedingungen und Messmethode
- Im Experiment wurden drei Faktoren konstant gehalten
- derselbe auf realen Open-Source-Anwendungen basierende IDOR-Datensatz
- Bewertung über den F1-Score gegenüber einer bekannten Menge echter Positivfälle
- derselbe IDOR-System-Prompt
- Verändert wurden Modell und Harness
- Semgrep Multimodal lief in einem Custom-Harness, das Endpoints auflistet und das Modell lenkt
- Claude Code lief über das Claude Code SDK
- Andere Provider-Modelle liefen über ihre jeweiligen nativen SDKs
- Open-Weight-Modelle wie GLM 5.2, MiniMax M3 und Kimi K2.7 Code liefen im Pydantic-AI-Harness nur per Prompt
- Verwendete Metriken waren
- Precision: Anteil echter IDORs unter den vom Detektor als IDOR markierten Fällen
- Recall: Anteil erkannter echter IDORs unter allen im Datensatz vorhandenen echten IDORs
- F1: harmonisches Mittel aus Precision und Recall
- Cost in dollars: Kosten pro echtem Positivfall sowie Gesamtkosten des Laufs geteilt durch die Zahl tatsächlich gefundener Bugs
Ergebnisse: dedizierte Harnesses auf Platz 1 und 2, GLM 5.2 auf Platz 3
- Das Ranking nach F1 bei der IDOR-Erkennung lautet wie folgt
- Semgrep Multimodal (GPT 5.5), Semgrep-Multimodal-Harness: 61 %
- Semgrep Multimodal (Opus 4.8), Semgrep-Multimodal-Harness: 53 %
- GLM 5.2, Pydantic AI Prompt only: 39 %
- Claude Code (Opus 4.6), Claude Code SDK: 37 %
- Claude Code (Opus 4.8/4.7), Claude Code SDK: 28 %
- MiniMax M3, Pydantic AI Prompt only: 23 %
- Kimi K2.7 Code, Pydantic AI Prompt only: 22 %
- GPT-5.5 Codex: 20 %
- Nemotron Super 3 120B, Pydantic AI Prompt only: 18 %
- DeepSeek V4, Pydantic AI Prompt only: 17 %
- Vergleich der Top-F1-Werte:
- Die Semgrep-Multimodal-Pipeline erreichte mit GPT 5.5 bzw. Opus 4.8 Spitzenwerte von 61 % und 53 %
- GLM 5.2 erzielte ohne Scaffolding 39 % F1
- Im Text heißt es, dass GLM 5.2 Claude Code um 7 Punkte übertraf
- Die Kosten für einen GLM-5.2-Lauf werden mit rund 0,17 $ pro gefundener Schwachstelle angegeben
- MiniMax M3 und Kimi K2.7 Code lagen mit 23 % bzw. 22 % unter GLM 5.2 und auch hinter Claude Code
- Der Abstand zwischen GLM 5.2 und dem nächstbesten Open-Weight-Modell beträgt 16 Punkte und ist damit größer als der Abstand zwischen GLM 5.2 und Claude Code
Einordnung und Grenzen
- Der größte Leistungsunterschied zeigte sich weniger zwischen den Modellen als zwischen Konfigurationen mit und ohne Endpoint-Erkennungs-Harness
- Das Harness erwies sich in diesem Experiment als ebenso einflussreich wie die Modellwahl
- Gleichzeitig übertraf GLM 5.2 unter Bedingungen mit minimalem Prompt und einfachem Harness Claude Code bei einer schwierigen Sicherheitsforschungsaufgabe, während die Kosten bei etwa 1/6 eines Frontier-LLM lagen
- Open-Weight-Modelle können in der eigenen Umgebung betrieben werden und könnten daher für einige Sicherheitsteams eine praktikable Wahl sein
- Die Ergebnisse haben klare Grenzen
- eine Aufgabe
- ein Datensatz
- ein Lauf
- IDOR-Erkennung ist nicht deterministisch
- der Datensatz ist endlich
- Bei der SSRF-Erkennung könnten sich die Ergebnisse umkehren; das ist bislang nicht überprüft
1 Kommentare
Meinungen auf Hacker News
Nach dem Wirbel um Fable und GPT 5.6 habe ich mir Open Models wieder angesehen, und GLM-5.2 ist für alltägliches Programmieren ein wirklich gutes, praxisnahes Modell.
Aus Sicht eines erfahrenen Entwicklers, der LLMs viel nutzt, kostet eine GPT-Session normalerweise über 100 Dollar; an diesem Wochenende habe ich einen Matrix-Bot mit Verschlüsselung und einen Rust-Agenten mit ein paar Tools gebaut, und zwei Tage später, nachdem ich 20 Dollar ausgegeben hatte, war daraus ein multimodaler Rust-Agent geworden, der auf mein Homelab zugreifen kann.
GLM fühlte sich nicht holprig an, erledigte gut, was ich wollte, war schnell, seine „Persönlichkeit“ störte kaum, und es war deutlich günstiger als Opus oder GPT. Ich habe bei Fireworks die nicht quantisierte Version genutzt; es gibt auch mehrere andere Anbieter.
Alle Labore bringen, ob absichtlich oder nicht, Modelle heraus, die Benchmark-Antworten auswendig gelernt haben; bei Modellen chinesischer Labore war die Lücke zwischen öffentlichen Benchmarks und unserer eigenen Evaluation tendenziell größer, und unsere Evaluation ist so gestaltet, dass sie weniger anfällig für Benchmark-Optimierung ist.
In Multi-Agent-Coding-Umgebungen liegt GLM 5.2 im Durchschnitt leicht hinter Opus 4.6. Die Daten stehen unter https://gertlabs.com/rankings.
Betrachtet man allerdings die Leistung im Verhältnis zu den Kosten, ist GLM 5.2 ein Frontier-Modell.
Als GLM 5.2 herauskam, habe ich es zu einem Benchmark zur Suche nach Sicherheitsbugs hinzugefügt; die Leistung war gut, aber es war nicht das beste Open Model.
Dieser Benchmark testet, ob ein Modell die Bugs finden kann, die Mythos gefunden hat. In den ersten Ergebnissen war das beste Open Model DeepSeek V4 Pro oder MiMo 2.5 Pro, aber MiMo scheint Glück gehabt zu haben und war danach in fast allen Tests schlechter. DeepSeek dagegen lag konstant weit oben und ist dank extremer Caching-Leistung günstiger als fast alles andere, einschließlich deutlich kleinerer Modelle.
https://swelljoe.com/post/will-it-mythos/
Ein weiterer interessanter Punkt ist, dass einige Modelle schlechter werden, wenn man ihnen Open-Source-semgrep als Tool bereitstellt, und kein Modell dadurch besser wurde. Es könnte eine Möglichkeit geben, den Harness so gut anzubinden, dass die Modelle nur nützliche Informationen erhalten, ohne semgrep direkt bedienen zu müssen.
Meine Vermutung ist, dass semgrep nicht stark in den Trainingsdaten vertreten ist, sodass man das Modell gleichzeitig dazu bringt, die Nutzung von semgrep zu verstehen und Sicherheitsbugs zu finden; dadurch wird die Aufmerksamkeit aufgeteilt, und beides wird schlechter. Die meisten kleinen Modelle und einige große Modelle schaffen das nicht gut.
Weitere Tests laufen noch, und es sieht sehr wahrscheinlich aus, dass GLM 5.2 dauerhaft stark abschneiden wird. In den meisten bisher getesteten Fällen war es hervorragend.
GLM 5.2 soll ein Modell mit 753B Parametern sein [1]; mich würde interessieren, welche Hardware man nutzt, um das lokal laufen zu lassen.
[1] https://huggingface.co/zai-org/GLM-5.2
Selbst auf eine 1-TB-NVMe passt es nicht unverändert, also habe ich das UD_Q4_K_XL-Quantisierungsmodell mit 4 Bit pro Gewicht genutzt; die Geschwindigkeit lag nicht bei Tokens pro Sekunde, sondern bei etwa 12 Sekunden pro Token. Es war ein interessantes Projekt, aber nicht sinnvoll nutzbar.
llama.cpp unterstützt Memory Mapping, also habe ich es mit einem Kontext-Cache von 4096 Tokens gestartet; da nicht alles in den RAM passt, wollte ich wissen, wie viel vom SSD gestreamt werden muss. Um eine einfache Selbstvorstellung mit 4 Sätzen zu generieren, wurden etwa 1,5 TiB von der Platte gelesen.
Aber keine Sorge: Open-Source-Evangelisten werden dir sagen, dass solche Modelle in drei Jahren auf dem Handy laufen.
Mit 100.000 Dollar könntest du dieses Modell über OpenRouter 10 Jahre lang rund um die Uhr mit 50 tps und 10 gleichzeitigen Sessions betreiben und hättest noch Geld für Urlaub übrig. Wenn du kein Unternehmen bist, das bereits für den individuellen Tokenverbrauch mehrerer Mitarbeiter bezahlt, gibt es keinen Grund, solches Geld in lokale Modelle zu investieren.
Die Formulierung „schlägt Claude Code (32 %) für etwa 0,17 Dollar pro gefundener Schwachstelle“ ist ungenau.
Claude Code ist kein LLM, sondern ein Agent-Harness, und Claude ist nicht ein einzelnes LLM, sondern eine Marke bzw. ein Bündel von LLMs.
Die Consumer-API ohne Enterprise-Vertrag ist sehr teuer, weil die Grenzkosten für Nutzer hoch sind und Anthropic hohe Margen hat. Wenn man approximieren will, was es einen staatlichen Angreifer kostet, ein Modell auf eigener Hardware zu betreiben, ist Claude Code vermutlich die beste Schätzung der amortisierten Kosten.
Diese Zahlen wirken ziemlich niedrig, besonders im Vergleich zu dem, was ich beim Windows-Kernel und im Bereich win32k↔win32u erreicht habe.
Es würde mich inzwischen nicht mehr überraschen, wenn China in bestimmten Kategorien wie Cyber beginnt, die öffentlich veröffentlichten Modelle der USA zu überholen.
GLM 5.2 ist bereits stark genug, um das eigene Training zu unterstützen, und das ähnelt dem Verlauf, den wir bei Frontier-Modellen gesehen haben. Außerdem scheint es dieses Niveau zu deutlich niedrigeren Kosten zu erreichen als OpenAI oder Anthropic.
Zusammen mit Chinas zunehmender Dominanz bei Solarenergie, Akkus und Elektroautos könnte das der Wirtschaftsordnung nach dem Zweiten Weltkrieg den entscheidenden Schlag versetzen.
Opus sollte zumindest mit demselben Pydantic-Harness laufen, das für GLM verwendet wurde. So wie es jetzt ist, vergleicht man Äpfel mit Birnen.
Wo sind die Kosten pro Schwachstelle für alle anderen Modelle außer GLM?
Ohne Code ist das schwer zu glauben. Es könnte alles ausgedacht sein.
Kommen bald Exportkontrollen für GLM? Ich erwarte, dass Commerce OpenRouter und HuggingFace innerhalb weniger Monate dazu zwingt, einige offene Modelle zu entfernen.
Sinn ergeben würde das allerdings nicht.
Ein Verbot von Open-Source-Modellen hilft überhaupt nicht, das Problem zu lösen. Angreifer fühlen sich nämlich nicht an Gesetze gebunden. Für Verteidigungszwecke müssen alle fortgeschrittenen Modelle zugänglich sein.
Die Regierung hat die Befugnis, (a) den Export amerikanischer Waren und Dienstleistungen zu verhindern, (b) den Import physischer Waren zu verbieten und (c) Transaktionen mit ausländischen Unternehmen zu untersagen, einschließlich des Kaufs von Dienstleistungen oder des Abschlusses von Lizenzverträgen.
Aber wenn ein US-Unternehmen eine vom Anbieter unabhängige Beziehung hat und das Modell weder für Regierungsaufträge noch für regulierte Anwendungen nutzt, sehe ich nicht recht, welche rechtliche Befugnis es gäbe, allein das Ausführen eines in China entwickelten Open-Source-KI-Modells innerhalb der USA zu verbieten.
Es ist möglich, dass man HuggingFace und anderen anordnet, chinesische Konten zu sperren. Aber wenn jemand in den USA oder einem Drittland das Modell aus China herunterlädt und es anschließend völlig unabhängig vom Anbieter wieder auf US-Server hochlädt, frage ich mich, wo der rechtliche Anknüpfungspunkt wäre, um das zu verbieten.
Ich nutze GLM 5.2 über Neuralwatt, und es ist so billig geworden, dass ich wohl mein persönliches Claude-Abo kündigen kann, wenn meine Firma mir ein Claude-Abo bereitstellt.
Diesen Monat habe ich 374 Millionen Tokens verbraucht, und mit der energiebasierten Preisgestaltung hat es nur 18 Dollar gekostet.
Liest sich wie Werbung.
Zweitens sind das „nur“ IDORs, und die gehören zu den einfachsten Arten von Schwachstellen.
Drittens wird hier mit GPT 5.5 und Opus 4.8 verglichen.
Nein, bei uns zu Hause gibt es kein Mythos.
Wenn es wirtschaftlich hätte angeboten werden können, wäre es vom ersten Tag an veröffentlicht worden statt des Marketingzirkus, den die Clowns des effektiven Altruismus veranstaltet haben. Es wäre nämlich ziemlich fatal gewesen einzugestehen, dass die Inferenzkosten für ein Modell, das weniger als 10 % besser ist, um mehr als 1000 % höher liegen.
Es ist ein wirklich starkes Modell, um Schwachstellen zu finden und zu beheben.
Aus EU-Sicht ist es noch komplizierter. Mythos könnte irgendwann in den Raum kommen und dann aufgrund der Launen eines politischen Akteurs, über den wir keinerlei Kontrolle haben, plötzlich wieder verschwinden.
Es ist wichtig zu wissen, wie weit offene Modelle gekommen sind, die zugänglich sind und lokal laufen können. Ich weiß, dass sie zurückliegen. Aber es kommt ein Punkt, an dem „gut genug“ nützlich wird. Das gilt auch dann, wenn es heute „nur IDOR“ ist und hinter dem neuesten Stand zurückliegt.
Wie oben jemand gesagt hat, werden Modelle derselben Klasse wie GLM 5.2 sowie Kimi und DeepSeek V4 zunehmend gut genug, um automatisierte Repository-Vorbereitungsarbeit zu unterstützen, also Download, Installation, Tests, Fixes und erneute Tests. Das führt zu Nutzungs-Trace-Daten aus der Praxis, die für das Training der nächsten Generation verwendet werden können. Das könnte wichtiger sein als die Frage, wie viele Prozentpunkte sie in Benchmarks zurückliegen.