Z.ai’s Models Found 2,436 Vulnerabilities.

On August 14, 2026, AI lab Z.ai released GLM-5.3 and reported that its models found 2,436 software vulnerabilities across 269 open-source projects, including the Linux kernel, Redis, WebKit, and FreeBSD, with 53 disclosed and 2,383 under embargo. The lab delayed the downloadable weights of GLM-5.3, targeting around August 28 for safety evaluation, but as of that date the weights had not appeared, while the smaller GLM-5.3-Flash was released under an MIT licence on August 26. Z.ai stated that cyber capability 'developed faster than we expected' during scaled post-training, and the article argues that the scarce resource in software security has shifted from finding vulnerabilities to fixing them, as many projects lack the capacity to remediate quickly.

There is a particular kind of silence that follows a very productive week. On August 14, 2026, the AI lab Z.ai published a model and a ledger. The model was GLM-5.3. The ledger listed 2,436 software vulnerabilities the lab says its models found across 269 open-source projects a cumulative count running from GLM-5.2 through GLM-5.3, rather than the output of a single release — including the Linux kernel, Redis, WebKit and FreeBSD. Of those, 53 had been disclosed. The other 2,383 were under embargo. Read that pair again, because it is the whole story. About two percent of the findings are out in the open. Ninety-eight percent are in a queue. Nearly every write-up of the GLM-5.3 vulnerability findings focused on the release decision: the lab held the downloadable weights, targeting around August 28 for safety evaluation and hardening — its first delayed GLM weight release — after cyber capability “developed faster than we expected” during scaled post-training. That is a legitimate story. It is also the less consequential one. Here is the thesis, stated plainly so it survives being quoted out of context: the scarce resource in software security has flipped from finding vulnerabilities to fixing them, and the weight delay does nothing about the 2,383 findings already in the pipeline. Discovery is now something you buy by the token. Patch delivery still runs at the speed of whoever maintains the package — and we measured that speed. Key takeaways TL;DR: A model shipped in August 2026 with a hold on its downloadable weights because it got unexpectedly good at security work; the stated target of around August 28 passed with the flagship weights still unpublished. The industry read that as a story about model access. It is really a story about throughput. One lab’s evaluation run produced 2,436 vulnerability findings, 2,383 of them still undisclosed and waiting on fixes — while the projects on the receiving end ship at a cadence we measured directly, and for four in ten of the most-depended-on Python packages, that cadence over the last quarter was zero. Vulnerability discovery is scaling like software. Vulnerability remediation is still scaling like people. It shipped GLM-5.3 on August 14, 2026 through paid and controlled channels, while holding the downloadable weights and pointing at a target of around August 28. As of August 28, 2026 the flagship weights had not appeared: the zai-org/GLM-5.3 repository on Hugging Face was still a placeholder listing that date. The smaller GLM-5.3-Flash was released under an MIT licence on August 26, 2026. Z.ai stated that GLM-5.3 uses the same base model as GLM-5.2 and that every reported gain came from roughly a month of expanded post-training — more task environments, a broader work mix, more compute. It had deliberately included vulnerability-discovery work, but says the model progressed from finding isolated flaws toward planning complete exploitation chains: "as we scaled post-training, cyber capability developed faster than we expected." The delay is a notable first for this lab’s open-weight line. It is also narrower than the headlines suggest. The model itself was already available at launch — through a paid coding plan, a hosted environment, and a trusted-access tier for selected security partners. What is being delayed is not capability access. It is irreversibility . A gated API can be rate-limited, logged, revoked and re-tuned after the fact. Published weights cannot. Z.ai acknowledged as much: once the weights are public, it will no longer control how people modify or use the model. Two weeks of hardening buys a better starting point for a permanent release, not a smaller total capability footprint. The frontier is broadly converging on metered release here — the strongest competing cyber model is behind a verified-partner program, and another lab ships its security-specialised model only to vetted defenders. But all of that operates on future capability, not on the findings already produced. They are 2,436 entries in a ledger Z.ai published on August 14, 2026, covering 269 open-source projects after what the lab describes as expert review, screening and deduplication. The severity breakdown is 107 critical and 990 high — 1,097 findings in the top two bands. Named affected software includes the Linux kernel, Redis, WebKit and FreeBSD. Only 53 had been disclosed; 2,383 remained under embargo. Two details in that ledger deserve more attention than they got. The first is age. Z.ai reports the listed vulnerabilities had gone undiscovered for an average of 26.6 years , with the oldest introduced in 1981 . These are not new bugs created by new code. They are old bugs nobody could afford to look for. That reframes the whole event: the software did not get worse this month. The economics of noticing got better. The second is provenance. Every cyber number here — benchmark scores and ledger alike — comes from Z.ai’s own harness and configuration, and no independent evaluator had replicated the results at the time of writing. On the benchmarks, the model ran at maximum reasoning effort with one attempt per task and no per-task time limit. That is a standard caveat for self-reported evaluations, and it matters here because the ledger is the load-bearing number for our argument as much as for the lab’s. Because the two capabilities are not moving at the same speed, and the slower one is the one everybody is afraid of. On CyberGym — 1,507 tasks from 188 software projects, oriented around finding and confirming known flaws — Z.ai reported GLM-5.3 at 84.5%, up from GLM-5.2’s 77.2%, ahead of the 83.8% and 83.6% it reported for two frontier competitors. That is the number that produced the headlines. Move one step up the chain, to turning a flaw into a working attack, and the ranking inverts. On ExploitBench, GLM-5.3 scored 54.4% — a large jump from GLM-5.2’s 24.4%, but well below the 78.0% Z.ai reported for the strongest comparison model. GLM-5.3 against the strongest comparison Z.ai reported, by stage of the work: All figures as reported by Z.ai on August 14, 2026, from its own evaluation configuration; not independently replicated. So the model that triggered a weight delay is, on the lab’s own numbers, roughly at parity for discovery and meaningfully behind for exploitation . The capability that arrived first is the one that generates work for defenders. That is good news, and almost nobody said it. It is also a warning, because it tells you which queue overflows first. We’ve written before about how the offensive side of agentic AI is bottlenecked by mundane operational competence rather than raw intelligence https://medium.com/p/cc32fa71bdb2 — same shape of finding: the scary part scales slower than the tedious part. Not at the rate the findings are arriving — and this is where we stopped reading press releases and measured something ourselves. The claim we wanted to test: if one evaluation run can produce 2,436 findings, what does the receiving end look like? Not “are maintainers good?” — they are — but “how often does a fix physically ship?” Release cadence is the hard ceiling on remediation. A patch in a commit but not in a published artifact protects nobody downstream. On August 20, 2026 , we pulled the complete release history for 84 of the most widely depended-on packages on PyPI the transitive core almost every Python service inherits: requests, urllib3, cryptography, numpy, pyyaml, jinja2, sqlalchemy, protobuf and so on from the public PyPI JSON API, using each release's earliest file upload timestamp, then repeated it for 46 core npm packages from the public npm registry. Per package we measured releases published in the previous 24 months and days elapsed since the most recent release. Sample: 130 packages, 2,379 PyPI release events in the window — reproducible from two public JSON endpoints in about ninety seconds. Here is what came back, and it is not what our first cut said. Release cadence as of 2026–08–20, PyPI n=84 against npm n=46 : Four in ten of the most-depended-on Python packages we sampled had not shipped a single release in the previous quarter. Five had shipped nothing in two years: python-dateutil, itsdangerous, colorama, sniffio and cycler — packages sitting underneath an enormous amount of production Python. The npm pattern is the same, milder: minimist, babel-core and moment had no releases in 24 months. Our first pass measured the median gap between consecutive releases and got 2.0 days — a hyper-responsive ecosystem. It was an artifact. boto3 and botocore, which publish on a near-daily automated train, contributed 972 of the 2,379 release events by themselves, and the top ten packages accounted for 62.0% of all release events across all 84. A handful of industrial release pipelines were drowning out the median project. Switching from “gap between releases” to “days since last release, per package” inverted the conclusion. Worth naming, because that averaging error is everywhere in supply-chain dashboards. Being explicit about the limits, because they are real: Those caveats bound the claim; they do not dissolve it. Even read charitably, the median package in the transitive core of a modern Python service ships roughly every six weeks, and a substantial minority ship on a scale of quarters. That is the machine 2,383 embargoed findings will eventually be fed into. Yes — and this is the strongest argument against our framing, so let us make it properly rather than knock it down. Embargo is not a backlog. It is a deliberate mechanism: findings are held precisely so maintainers get time to fix before details go public. A ledger with 2,383 entries under embargo and 53 disclosed is, on this reading, a disclosure process working as designed — evidence that nobody dumped 2,436 zero-days onto the internet. The steelman goes further. Distributions backport security fixes independently of upstream release trains, so upstream cadence understates real patch delivery. Large projects have out-of-band release paths that bypass normal versioning. And a finding is not a vulnerability until it is triaged — machine-generated candidates historically carry meaningful false-positive rates, so 2,436 findings may represent considerably fewer real, reachable bugs after human review. All of that is correct, and it changes the magnitude of the problem rather than its direction. Coordinated disclosure was designed for a world where finding a serious flaw in a mature codebase was itself the expensive, rate-limiting step. That assumption is what changed. A process tuned for scarcity behaves differently when the input becomes abundant: the queue lengthens, triage becomes the constraint, and embargo windows get set by reviewer availability rather than fix complexity. The mechanism is not broken — it is being asked to run at an input rate it was never sized for. Same lesson we drew from algorithmic discovery systems, where the evaluator turned out to be the real product rather than the model https://medium.com/p/86b8e93f1ce2 : the generator got cheap, and everything downstream of it did not. Nothing dramatic, and nothing that requires predicting how this resolves. Four things that are cheap now and expensive later: None of this depends on when the weights ship, or on whose benchmark you believe. It depends only on the ledger existing, which it does. Z.ai cited safety evaluation and hardening after GLM-5.3’s cybersecurity capability improved faster than expected during post-training, and set the downloadable weights for release around August 28, 2026 — its first delayed GLM weight release. As of that date the flagship weights had not been published, while the smaller GLM-5.3-Flash was released under an MIT licence on August 26. The model itself shipped on August 14 through paid and controlled channels, so the delay restricts modifiable, unrevocable access rather than access to the capability itself. Z.ai’s ledger listed 2,436 findings across 269 open-source projects as of August 14, 2026, after what the lab describes as expert review, screening and deduplication. The count is cumulative across GLM-5.2 and GLM-5.3 rather than attributable to GLM-5.3 alone. The severity split was 107 critical and 990 high. Only 53 had been disclosed publicly; 2,383 remained under embargo. Named affected software included the Linux kernel, Redis, WebKit and FreeBSD. Only at one stage of the work. On CyberGym, which tests finding and confirming known flaws, Z.ai reported 84.5% for GLM-5.3 against 83.8% and 83.6% for two frontier competitors. On ExploitBench, which tests turning flaws into working attacks, it reported 54.4% against 78.0% — a 23.6-point deficit. All figures come from Z.ai’s own evaluation harness and have not been independently replicated. Slower than most dependency dashboards imply. In our own measurement on August 20, 2026, 39.3% of 84 of the most-depended-on PyPI packages had published no release in the previous 90 days, and 15.5% had published none in a year; on npm the figures were 28.3% and 6.5% across 46 core packages. Release cadence is a capacity proxy, not a measure of emergency response — large projects do ship out-of-band security fixes. One question we’d actually like answered, because our measurement can’t reach it: for the last security advisory that affected you, how many days passed between the upstream fix being released and it running in your production environment — and what was the specific step that took the longest? Written by Decoding AI . We measure the AI claims everyone repeats, and publish the numbers — including the ones that weaken our own argument. Z.ai’s Models Found 2,436 Vulnerabilities. https://pub.towardsai.net/z-ais-models-found-2-436-vulnerabilities-d89f1cc098d6 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.