AIEvals

Benchmarks

ExploitBench

How far up the exploitation ladder an agent climbs on a production JavaScript engine: reaching vulnerable code, triggering the bug, building an exploit primitive, and finally achieving arbitrary code execution, with sixteen capabilities measured per run.

SecurityExploitBench (exploitbench.ai)Vendor-reported onlyReported by Z.ai

How it is run

The first benchmark in the set, v8-bench v0.1, targets V8 with its security sandbox enabled and grades runs against production V8 rather than a stripped-down build. Z.ai reports its own GLM-5.3 and GLM-5.2 figures under its harness in the table reproduced here.

What it cannot tell you

The benchmark's own front page mixes run parameters — seeds, turn budgets and harness configurations differ between models — and says so, offering a fixed-experiment view for comparisons. Read a publisher column as one lab's setup, and use the benchmark's own control view before ranking two models that are close.

Why there is no independent table

No independent suite in this dataset runs ExploitBench. The numbers below are the ones model publishers report about their own models, which is a different kind of evidence: each publisher chooses its own harness and effort level, so a row is readable on its own and not against the other rows.

Read this with

Benchmarks in the same category, which usually disagree with this one on purpose.

  • CWE-bench v1Same category. Remediating software security vulnerabilities, measured as the share of tasks successfully completed.
  • CyberBench v1.1Same category. Whether autonomous agents can find and trigger real vulnerabilities in open-source projects by submitting a proof-of-concept input, and produce a source patch that fixes the bug without breaking behaviour.
  • SRE BenchSame category. Whether an agent can work out what a real-world binary does without its source code: reverse engineering across network protocols, firmware, games, file-format recovery and malware.
  • CyberGymSame category. Whether an agent can analyse real vulnerabilities in large, long-lived codebases — the work of a security researcher rather than a quiz about security.
  • SEC-bench ProSame category. Whether an agent can find security bugs in critical software — V8, Firefox and the Linux kernel — under a fixed time budget.
  • ExploitGymSame category. Whether a model can turn a known vulnerability into a working exploit, reported as a Pass@1 rate alongside the other cyber-security evaluations.

As reported by each publisher

Kept separate per publisher, because the settings are not shared.

Z.ai

GLM-5.3: Frontier Coding with Emergent Cyber Capabilities — evaluation table · 14 August 2026

RankModelScore
3GLM 5.354.4%
7GLM 5.224.4%
5Kimi K332.2%
6Qwen3.8 Max28.8%
4Claude Opus 4.840.0%
1Claude Fable 578.0%
2GPT-5.6 Sol76.5%

Ranks compare reported scores in the same published row; ties share a rank.

The comparison table Z.ai publishes with GLM-5.3, read on the model card itself. Z.ai states that GLM-5.3 uses the same base model as GLM-5.2 and that every gain comes from post-training, so the GLM-5.2 column is the same architecture one training round earlier. Column names were restated in the form this site uses, and Z.ai labels its own Fable column "Fable 5 (w/ fallback)", which is recorded here as Claude Fable 5 and is the only column whose runs used a fallback model. Rows whose scale is not a percentage keep their own unit: ExploitGym is reported as tasks completed with a 2-hour and a 6-hour budget and is split into two rows so both numbers stay readable, and GDPval-AA v2 is a score rather than a percentage. The table is the only source for several benchmarks on this site, and nothing in it is an independent run.

z.ai/blog/glm-5.3

Sources

Every page used for this benchmark, read on 17 October 2026.