Z.ai on X: "https://t.co/fbjLdFGKez" / X<br>Post
Log inSign up
Post
Z.ai
@Zai_org
Preparing GLM-5.3 for Open Release: A Responsible Path to Cyber Defense<br>When GLM-5.2 helped Hugging Face investigate an incident in which an AI autonomously bypassed its own safeguards, it highlighted a broader shift. AI is becoming part of both cyber offense and cyber defense.<br>As powerful cyber capabilities become more accessible, strong defensive capabilities cannot remain limited to a small number of well-resourced organizations. Open-source maintainers, independent researchers, developers, and smaller security teams also need tools that can help them find and fix vulnerabilities before they are exploited.<br>An open world cannot have only open attack surfaces. It must also have an open shield.<br>GLM-5.3 is our most capable model to date for cybersecurity tasks. It delivers substantial improvements in vulnerability discovery, exploit analysis, and complex multistep security tasks. These capabilities can help defenders identify weaknesses earlier, validate risks, and accelerate remediation.<br>They also create clear dual-use risks. We are therefore taking a staged approach to release. Selected security partners will first evaluate GLM-5.3 in controlled settings. Broader access and API availability will follow. Once the necessary safety evaluations and release preparations are complete, we will publish GLM-5.3’s complete model weights.<br>Responsible openness does not mean treating every capability as harmless. It means evaluating risks transparently, strengthening safeguards before release, coordinating the disclosure of validated vulnerabilities, and expanding access to advanced defensive capabilities in ways proportionate to the risks.<br>From vulnerability discovery to multistep security analysis<br>As part of post-training, we introduced vulnerability discovery data and authorized security environments into the training mix. We expected this to improve the model’s ability to find and analyze vulnerabilities.<br>As training scaled, the improvement extended beyond isolated flaws. GLM-5.3 became more effective at connecting vulnerability conditions, program behavior, validation paths, and potential impact across multiple stages of analysis.<br>We evaluate these capabilities across three benchmarks:<br>CyberGym begins with white-box source code and tests whether a model can identify and validate vulnerabilities by triggering faults. GLM-5.3 scores 84.5%, compared with 77.2% for GLM-5.2.<br>ExploitBench requires deeper reasoning about real vulnerabilities and their exploitation. GLM-5.3 reaches 54.4%, more than twice GLM-5.2’s 24.4%.<br>ExploitGym measures completed exploitation tasks under normalized evaluation budgets. GLM-5.3 completes 105 tasks within two hours and 130 within six hours, compared with 29 and 39 for GLM-5.2.<br>The pattern is consistent. GLM-5.3 improves most over GLM-5.2 as tasks move from isolated vulnerability discovery toward multistep exploitation. The results also show where further progress is needed, particularly on the most complex end-to-end tasks.<br>From benchmarks to real software<br>We have also worked with universities and professional security teams to evaluate GLM models on real-world codebases in authorized settings.<br>Across this work, the GLM series has produced 2,436 vulnerability findings across 269 projects, including 1,097 categorized as medium-to-high severity. These findings span system software, operating systems, browser engines, open-source infrastructure, web applications, network protocols, and intelligent devices. Some of the underlying issues had remained unnoticed for decades.<br>In these evaluations, security experts establish the authorized scope, review model outputs, investigate potential risks, and coordinate with the relevant parties. GLM models can help researchers reconstruct complex program logic, narrow large numbers of candidate paths, and connect evidence across multiple components.<br>The purpose is not simply to generate more findings. It is to help defenders identify meaningful risks earlier and reduce the time between discovery and remediation.<br>Discovery must be followed by responsible disclosure<br>A vulnerability is not safely handled at the moment it is discovered. It must be reviewed, reproduced where appropriate, reported through the proper channels, and coordinated with the affected maintainers.<br>Findings from our security work are submitted through established disclosure processes. We publish technical details only when doing so is consistent with the relevant disclosure and remediation process. For issues that remain under coordination, we do not release information that could unnecessarily increase risk or identify affected projects.<br>To make this work more transparent, we created the Z.ai Security Disclosure Ledger.<br>The ledger records findings as they move through the disclosure process. For publicly disclosed issues, it may include the affected project, severity, a CVE or other identifier where...