# Preparing GLM-5.3 for Open Release: A Responsible Path to Cyber Defense > Source: > Published: 2026-08-15 06:32:13+00:00 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. 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. An open world cannot have only open attack surfaces. It must also have an open shield. 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. 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. 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. From vulnerability discovery to multistep security analysis 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. 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. We evaluate these capabilities across three benchmarks: 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. 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%. 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. 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. From benchmarks to real software We have also worked with universities and professional security teams to evaluate GLM models on real-world codebases in authorized settings. 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. 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. 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. Discovery must be followed by responsible disclosure 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. 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. To make this work more transparent, we created the Z.ai Security Disclosure Ledger. 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 available, and information about how long the issue remained in the codebase. For vulnerabilities still under coordinated disclosure, the ledger can publish a cryptographic hash. This allows a finding to be verified later without prematurely revealing operational details. Opening a model and disclosing a vulnerability are separate decisions. Making a model more broadly available does not require publishing vulnerability details before maintainers have had an appropriate opportunity to investigate and respond. Safety and staged release Cybersecurity is a particularly difficult domain for AI safety. Offensive and defensive tasks often involve the same terminology, code, and technical methods. A request to analyze a vulnerability could come from a maintainer preparing a patch, a student solving a CTF challenge, a researcher conducting an authorized assessment, or an attacker targeting a real system. Keywords alone cannot reliably distinguish these cases. Intent, authorization, context, target, and potential impact all matter. For GLM-5.3, we use a defense-in-depth approach with three complementary layers. External classifier In our hosted services, an external classifier identifies high-risk requests and helps prevent clearly harmful activity. Reasoning monitor A reasoning monitor assesses risk during task execution. It is designed to detect harmful objectives that may emerge across multiple steps rather than relying only on the wording of the initial request. Deep safety alignment The model itself is trained to distinguish legitimate security work from high-risk offensive activity and to refuse requests that cross that boundary. Deep safety alignment is particularly important for an open-weight release. Hosted classifiers and monitors apply to our services, but they do not automatically accompany the model into every local deployment. Model-level alignment is the safety layer included in the released checkpoint. To develop these systems, we created differential training data that reflects both the similarities and the differences between authorized security research and malicious activity. We also constructed adversarial data covering jailbreak variants, disguised intent, and other attempts to evade safety review. Our evaluations cover a range of cybersecurity tasks, including: security education and knowledge; blue-team defense; CTF challenges; vulnerability discovery and remediation; authorized penetration testing; exploit development; unauthorized intrusion and other clearly malicious activity. The objective is to reduce high-risk abuse without broadly refusing legitimate defensive, educational, and research tasks. Before broader release, professional security teams will conduct safety evaluations and red-team testing. These evaluations examine both whether the model can be manipulated into supporting harmful activity and whether its safeguards interfere with legitimate security work. No safety system can eliminate every dual-use risk. Once model weights are public, no developer can guarantee control over every downstream modification or use. Model-level safeguards can raise the barrier to abuse, but they cannot provide absolute control. Our release process therefore focuses on the stages where meaningful risk reduction is possible: training, pre-release evaluation, controlled partner testing, hosted-service safeguards, responsible disclosure, and continuing adversarial testing. Launching the OpenVuln initiative Much of the world’s digital infrastructure depends on open-source software. Many critical projects are maintained by small teams or individual contributors without dedicated security resources. At the same time, AI is making complex cyber tasks easier to automate. If advanced defensive capabilities remain concentrated within a small number of organizations, the projects with the fewest resources may be left protecting some of the most important parts of the software supply chain. To help address this imbalance, we are launching the OpenVuln initiative alongside GLM-5.3. Continuous support for open-source security We will work with maintainers to audit important open-source projects, identify potential vulnerabilities, and support responsible disclosure and remediation. Maintainers can use OpenVuln to submit projects for security review and learn more about the process. A shield for the open world GLM-5.3 shows that open models can become meaningfully stronger at vulnerability discovery, exploit analysis, and complex security reasoning. That progress carries real defensive value and real dual-use risk. Our responsibility is to direct these capabilities toward finding vulnerabilities earlier, supporting responsible remediation, and strengthening the open-source systems on which everyone depends. Following staged evaluation and broader API access, we intend to release GLM-5.3 as an open-weight model. We will continue improving model-level safeguards, testing adversarial use, and supporting coordinated disclosure throughout that process. The open world must have a shield of its own. Through GLM-5.3 and the OpenVuln initiative, we intend to make that shield more broadly available and to release it with care.