An AI model found a serious security flaw in Cursor — what it means for teams betting on AI coding tools
Z.ai's newly released GLM-5.3 model flagged a potentially serious vulnerability in the Cursor code editor within days of launch, part of a broader pattern of AI models now finding security flaws in the very AI coding tools founders are commissioning apps with.
17 August 2026
Z.ai released its GLM-5.3 model on 14 August 2026, and its headline result arrived almost immediately: security researcher Joshua Saxe flagged that the model had identified a potentially serious vulnerability in Cursor, one of the most widely used AI code editors, involving Cursor’s Rust/Electron architecture and a risk of arbitrary file write. Cursor’s team is working on a fix; the flaw was disclosed privately rather than published. What makes this newsworthy isn’t the individual bug — IDEs get vulnerabilities disclosed all the time — it’s the benchmark context. GLM-5.3 scored 84.5% on CyberGym, a vulnerability-discovery benchmark, ahead of comparable frontier models, and its score on ExploitBench (which measures a model’s ability to reason through and actually execute an exploit) more than doubled from its predecessor, to 54.4%. Z.ai says the improvement came from post-training reinforcement learning specifically on security tasks — and that its models have now collectively surfaced 2,436 vulnerabilities across 269 projects since the prior release.
The pattern to notice: AI models capable of writing production code are increasingly also capable of finding — and, in principle, exploiting — flaws in the tools other AI models run inside. Cursor, Claude Code, GitHub Copilot and similar tools now sit deep inside real company infrastructure, often with repository access, shell access and the ability to run commands unattended. A vulnerability in the editor itself, not just in the code it generates, is a different category of risk than “the AI wrote a bug” — it’s “the tool you gave repo and terminal access to has an exploitable hole.”
So what
This isn’t a reason to avoid AI coding tools — it’s a reason to treat which one you standardise on, and how it’s configured, as a real engineering decision rather than a personal preference. Teams commissioning software built with AI-assisted workflows should ask their delivery partner what tooling they run, what access it has, and how quickly it patches. We build with these tools deliberately, with sensible limits on what any agent can touch in a client’s environment — see our AI-assisted development approach, or get in touch if you want a straight answer on how a project would actually be built.