decrypted · 22 september 2026 · uk policy and law · ai and llm security · surveillance and privacy

A masterkey to every case file: the Ministry of Justice's Southport breach

The Ministry of Justice has apologised after court staff accessed case files belonging to victims, survivors and families of the July 2024 Southport attack without authorisation. The breach surfaced during a routine review of digital systems, not because any system flagged it, and for a limited number of people the material accessed was assessed as likely to cause a high risk to their rights and freedoms. It follows two earlier breaches touching the same group: inappropriate access to medical records at a Liverpool hospital and at North West Ambulance Service. None of these three incidents was a hack. Each was a permissions problem, someone who should never have been able to open a file, did, and the lesson is squarely about how UK organisations design access to their most sensitive records.

What actually happened

HM Courts and Tribunals Service and HM Prison and Probation Service are investigating how staff came to view files they had no professional reason to see. The Ministry of Justice has declined to say how many staff were involved, whether they still work there, or why they looked. What it has confirmed: the access was unauthorised, there is no evidence the information left the building, and the incident has been referred to the Information Commissioner's Office. The Prime Minister has asked the Lord Chancellor to oversee the inquiry personally, a sign of how seriously Whitehall is treating a breach involving the families of murdered children.

The design failure behind it

This is not a story about a clever attacker. It is a story about a case management system that, by default, let authorised users see files well outside their own caseload. That is an access control decision made at design time, not a lapse by an individual member of staff. Think of it as a hospital that issues every porter a master key to every ward, rather than a key that only opens the one they clean. Most staff never try the door. The design only fails you when one does, and by then the only way to find out is an audit, which is exactly how this breach was caught: after the fact, by people looking, not by a system that noticed and said so.

Why this matters beyond the Ministry of Justice

Secure by design, in NCSC's own language, means building least privilege and need-to-know into a system's default state rather than relying on staff discipline to compensate for an overly generous one. It also means the system itself should notice when someone touches a record they have no business touching, rather than waiting for a scheduled review months later. Courts, hospitals, police forces, social services and plenty of private-sector holders of sensitive personal data, family law firms, safeguarding charities, HR platforms, run on exactly this kind of shared case system. Any organisation holding records about people at their most vulnerable should ask two blunt questions this week: does our system enforce need-to-know by default, or does it trust staff not to look? And would we find out about an improper access in an audit six months from now, or would the system tell us today? Both answers are cheap to fix before a breach and expensive to explain after one.

Also this week

CISA flags three actively exploited Linux kernel flaws. CISA added CVE-2025-39682, CVE-2026-53266 and CVE-2025-39964 to its Known Exploited Vulnerabilities catalogue on 18 September, three Linux kernel flaws with active exploitation confirmed, one of them rated CVSS 9.8. US federal agencies must patch by 21 September and, unusually, must also check whether affected systems were already compromised rather than treating a patch as the end of the job. Red Hat says the three do not appear to be one coordinated campaign. Any UK organisation running affected kernel versions, a large share of cloud and on-premise Linux estates, should treat patching and compromise checks as two separate tasks, not one.

North Korea's WaterPlum drains 7,000 crypto wallets via fake job interviews. A joint advisory from the FBI, Japan's National Police Agency, Australia's ACSC and Germany's BfV, published 18 September, says the group has infected at least 30,000 devices across 100-plus countries since December 2025, using AI face-swapped video calls and fake coding tests to plant malware on developers' machines and drain over 7,000 cryptocurrency wallets, moving $10.71 million to Pyongyang. UK developers and recruiters in AI, crypto and Web3 hiring pipelines are named targets. Treat any unsolicited run-this-before-the-interview file as hostile by default, however convincing the recruiter looked on the call.

Plugin4Shell breaks the update chain in four AI coding agents. Researchers at AIR Security disclosed Plugin4Shell, a zero-click flaw letting a malicious repository owner swap in unreviewed code by naming a Git branch to look like a pinned commit hash, code that Claude Code, OpenAI Codex, GitHub Copilot and Gemini CLI then fetch and run automatically. Anthropic and OpenAI have shipped fixes; Microsoft has not, and Google is retiring the consumer Gemini CLI rather than patching it. If your developers use AI coding agents with third-party plugins, check which of these four tools you run and whether the fix has actually landed.

Sources

Building need-to-know into your systems from the start is cheaper than explaining a breach afterwards. If that sounds like a gap worth checking, get in touch.

More like this

Get the next post by email: subscribe to Decrypted. Double opt-in, unsubscribe any time, or take the RSS feed.

Prefer to listen? Decrypted on Apple Podcasts, or paste the podcast feed into any app.