Attackers no longer need a sympathetic AI provider. In 2026, an open-weight model with serious offensive ability became free to download, and modified versions with its refusals removed appeared within days.
This matters to hospitals for a specific reason: the gap between a public security fix and a working attack is shrinking faster than clinical systems can be patched.
We build and deploy AI for healthcare, and we recommend open-weight models for many clinical uses because they can keep patient data inside a hospital's own network. That recommendation stands. But the same properties that make these models useful to a hospital also make them useful to the people attacking it. This article sets out what is known, what is still unproven, and what healthcare teams should do now.
The short version
- The capability is real. NIST's Center for AI Standards and Innovation described GLM-5.3 as "the most cyber-capable open-weight model released to date."
- Guardrails are not a dependable control on an open-weight model. Once weights are public, anyone can change them, and no provider can recall them.
- Criminal interest is measurable. Researchers have found uncensored GLM variants being discussed and sold in underground channels.
- Hospital-specific attribution is still thin. As of November 2026, we have not seen a public report tying a specific Canadian hospital attack to an open-weight model.
- The right response is mostly unglamorous. Faster patching of exposed systems, removing stale accounts, testing offline backups, and segmenting clinical networks all still work.
What changed in 2026
Z.ai, the company also known as Zhipu AI, released GLM-5.3 on August 14, 2026 and titled its launch post "Frontier Coding with Emergent Cyber Capabilities." It later published the weights under a licence that permits modification and commercial use.
Three separate assessments describe what that means:
| Source | Finding |
|---|---|
| NIST CAISI | The most cyber-capable open-weight model released to date, though well below current US frontier models and about four months behind them on an aggregate of CAISI's benchmarks |
| Anthropic | Built end-to-end exploits in 50 of 410 attempts on ExploitBench, close to the 56 of 410 achieved by Anthropic's restricted Claude Mythos Preview |
| Z.ai | Reported 84.5% on the CyberGym vulnerability benchmark, up from 77.2% for GLM-5.2 |
Anthropic sells competing AI models, so its conclusions deserve some scrutiny. That is why the NIST assessment and Z.ai's own benchmark results matter: they point in the same direction.
One Anthropic test is especially relevant to hospitals. A researcher gave the smaller GLM-5.3-Flash model public details of two known Chrome flaws. It produced a working exploit chain in a sandbox with 20 minutes of human attention, eight hours of model time, and an estimated US$20.40 in API costs.
A single lab result does not predict every real-world attack. It does show why the old assumption, that attackers need considerable time and skill to weaponize a newly published fix, is becoming unsafe.
Jailbroken versus abliterated
These terms are often used interchangeably, but the difference matters for defenders.
| Jailbreak | Abliteration | |
|---|---|---|
| What changes | The prompt or conversation | The model itself |
| Where it works | Any model that can be manipulated | Models with downloadable weights |
| Can a provider respond? | On a hosted service, yes | Not once the weights are public |
| Monitoring | A hosted provider may detect abuse | None if run privately |
Anthropic tested how well GLM-5.3's safeguards held up in a simulated environment. Asked directly to carry out malicious attacks, the model refused every time. With a false cover story it engaged 64% of the time, with manipulated reasoning 92%, and with an abliterated copy 100%.
Removing the refusals cost Anthropic's inexperienced team about US$4,400 in compute, and it estimates an experienced team would need about US$1,200. General capability was largely unchanged.
The conclusion for a hospital is simple: treat vendor safety training as irrelevant to your threat model. It may reduce casual misuse, but it will not stop a motivated attacker running a modified model on their own hardware.
What attackers are actually doing
It is worth separating what has been observed from what is merely plausible.
Observed:
- Flare analyzed more than 100,000 Telegram channels and 100 dark web forums and found interest in abliterated models rose sharply around the GLM-5.2 and GLM-5.3 releases. GLM was the model vendors named most often.
- Google's Threat Intelligence Group reported attackers who compromised a cloud resource, then planned and ran an agent-enabled mass credential harvesting campaign in under six hours.
- The same report links suspected activity by UNC6508, a group that has targeted academic, medical, and military research institutions in North America, to local LLM infrastructure deployed in compromised cloud environments. Using a local open-weight model avoids commercial API monitoring and consumes the victim's own computing power.
- Anthropic's September 2026 threat report describes operators running multi-agent systems for reconnaissance, exploitation, and data theft, with people setting targets and reviewing what was stolen.
Plausible, but not yet publicly documented at scale: a ransomware crew using a private, guardrail-free model specifically to find flaws in PACS software, interface engines, or medical device management tools. We would plan for it, but we would not claim it has already become common.
Why healthcare is exposed differently
Most organizations can patch a web server tonight. Hospitals often can't.
An imaging archive may be tied to a vendor-validated configuration. An infusion pump server may need a supplier's sign-off. A change to an interface engine can interrupt lab results. So hospitals tend to have a long tail of systems that remain vulnerable long after a fix is published. Cheap, automated exploit development targets exactly that gap.
Recent Canadian incidents show how much is at stake, even where AI played no known part:
- In September 2026, a ransomware attack on Nipigon District Memorial Hospital in northern Ontario led to the temporary closure of outpatient laboratory and diagnostic imaging services, with staff moving to manual procedures.
- In August 2026, Winnipeg's Health Sciences Centre reported ransomware affecting facility systems, with reports of doors and HVAC being affected. Shared Health said it had no indication patients were affected.
- Ontario's Information and Privacy Commissioner published a case involving a medical imaging clinic where attackers likely entered through a dormant account with significant administrative privileges. They deleted backups, up to 550,000 patient records and 1.6 million case files could have been affected, and the clinic had to close temporarily.
- The Canadian Centre for Cyber Security notes that a 2023 attack on a shared IT provider forced five Ontario hospitals to shut down internal systems and delayed patient care.
The imaging clinic case is the one we would put in front of a hospital board. Nothing in it required advanced AI. A forgotten account and reachable backups were enough. AI makes it cheaper to find those weaknesses at scale, which is a strong argument for removing them now.
IBM's 2026 report puts the average healthcare breach at US$6.64 million, the highest of any industry for the 13th straight year. Patient harm from delayed care does not appear in that number.
A radiologist and a cybersecurity engineer discussing a clinical system in a radiology reading room
What proactive looks like: a 90-day plan
If we had 90 days with a hospital that hadn't done this work, this is the order we would follow.
| Priority | Action | Why it comes here |
|---|---|---|
| 1 | Find everything reachable from the internet, including vendor VPNs and remote access tools | You cannot defend what you have not listed |
| 2 | Remove dormant accounts and require phishing-resistant MFA for admin and remote access | This is the entry point in the IPC case |
| 3 | Test a full restore from offline or immutable backups, and time it | Backups that attackers can delete do not count |
| 4 | Set a faster patch schedule for exposed systems, with a compensating control where patching must wait | This directly addresses the shrinking exploit window |
| 5 | Segment PACS, interface engines, biomedical devices, and building systems | This limits how far one compromise can spread |
| 6 | Run a downtime exercise with clinical and executive leaders | Manual workflows and decision rights fail when untested |
None of this depends on knowing which model an attacker used. That is the advantage of a proactive program: it holds up against threats you can't name yet.
If you run open-weight models yourself
Hospitals deploying their own models should add a few controls of their own:
- Use verified sources. Download only from the original publisher and verify file hashes. Never put a community "uncensored" variant anywhere near clinical systems.
- Block outbound internet by default. A model server rarely needs to initiate connections.
- Scope every tool. An AI agent should have the minimum permissions for its task, with human approval for anything that changes a record.
- Enforce patient-level access in retrieval. A chatbot must not become a way around chart access controls.
- Log prompts, outputs, and tool calls, with retention that supports investigation.
- Watch your GPUs. Google has documented attackers hijacking enterprise cloud computing to run their own AI workloads. Unexpected GPU use is a security signal.
- Look for unapproved AI. IBM found that shadow AI was involved in 43% of breached organizations in 2026, according to Kiteworks' analysis of the report.
Defenders can also use these models. When Hugging Face investigated an incident in which hosted models refused legitimate forensic requests, it used GLM-5.2 on its own infrastructure to analyze the logs. For a hospital, a well-controlled local model could review logs or configurations without sending sensitive data to a third party.
What Canadian regulators now expect
In Ontario, O. Reg. 51/26 has applied since July 1, 2026 to Group A, B and C public hospitals and the University of Ottawa Heart Institute. They must name cyber security contacts, complete a maturity assessment every two years and submit a summary, and report critical incidents to the provincial CISO within 72 hours of confirmation.
PHIPA and other provincial health privacy laws continue to apply when personal health information is affected. Legal counsel should confirm how each requirement applies to your organization.
A maturity assessment is only useful if it reflects how your systems would hold up today. We would build it around the threat described here, not around last year's checklist.
Where to start
Start with one question: if a capable, tireless attacker looked at your hospital tonight, what would it find first?
If you don't know the answer, that's the first thing to fix. SofTx helps Canadian hospitals and clinics answer it, and then does the engineering work to close the gaps. Learn more about our healthcare cybersecurity services.
