Researcher with Claude on a laptop finds 100+ serious flaws in UK government code

What happened

Security researcher Chris Nesbitt-Smith of UK firm ControlPlane went through publicly available code from the British government and found more than 100 serious vulnerabilities. He looked at 349 repositories (project folders holding source code, mostly hosted on GitHub) from 33 public bodies and found problems in about two thirds of them. Wired broke the story, and outlets including Infobae and TechBooky later picked it up.

Nesbitt-Smith's tools were Anthropic's Claude Opus and Claude Sonnet. These weren't special builds. They were the same versions any customer gets, and he ran them on an ordinary laptop. He reported the flaws to the organizations involved, and according to Wired, all of them have since been fixed. Some of the findings go back months: several reports date from June, one from August.

The worst find: a key that never expired

The most dangerous slip came from the Planning Inspectorate, the agency that handles land use and planning matters in England. It had accidentally pushed a Microsoft Entra ID credential to GitHub. Entra ID is Microsoft's service for controlling who in an organization can access what. The file was later removed from the current version of the project. But according to ControlPlane, it stayed retrievable for 18 months through an old commit. A commit is a saved snapshot in a project's version history, and on GitHub that history is normally kept in full.

The key was still valid, apparently never expired, and carried sweeping permissions. Nesbitt-Smith says it would have given "god-like" read and write access to every SharePoint site and every staff member's private OneDrive account, HR files included. SharePoint and OneDrive are Microsoft's services for storing and sharing files. Also within reach were libraries of evidence held under legal hold, meaning it has to be preserved by law. That evidence relates to statutory planning procedures and appeals.

"The ability to ransomware them, encrypt all of their data, or just steal all of their data was more than there," Nesbitt-Smith told Wired.

Ransomware is malware that encrypts data and only unlocks it once a ransom is paid. TechBooky stresses that this is about potential access only. ControlPlane checked the permissions with limited, non-destructive tests and didn't pull any real files. An agency spokesperson told Wired that its monitoring systems spotted the researcher's activity in August straight away. It was already treating the incident as a cyber incident when ControlPlane got in touch. The hole was closed about 20 minutes after the tip-off, and no data was exfiltrated. The agency says it has improved its systems and processes and is grateful to the researcher.

TechBooky draws a broader lesson: deleting a password or key from the latest version of a repository doesn't invalidate it. You have to revoke it with the provider that issued it.

More flaws at the Department for Education and in Scotland

Several vulnerabilities were in code from England's Department for Education. According to Wired, they affected:

• a procurement service that schools use to buy goods and services,
• a teacher application portal holding personal details, qualifications, employment history and identity documents,
• the central register of government-funded training and apprenticeship providers in England.

In the school procurement form, TechBooky reports, anyone who knew a request's ID number could change that request without logging in. That's a textbook access control failure: the system never checked whether the request belonged to the person editing it. The department fixed the flaw in July.

On the Scottish Government's open data portal, an admin key with no expiry date was embedded right in the JavaScript that every browser downloads when it loads the page. That let any visitor read information about admin accounts and change the site's settings without logging in. ControlPlane reported it on June 23 through the Scottish Government's official vulnerability disclosure program. On June 25, the operator took the portal offline for good, since it no longer needed it anyway.

Not hacker magic, just sloppiness

Nesbitt-Smith stresses that this isn't about sophisticated AI attacks.

"None of this is at the level of sophistication that the mainstream media worries about with cyberattacks. It's all dumb stuff," he told Wired.

He says a routine IT security check should have caught many of the mistakes. Typical problems were credentials with far too many permissions and missing authorization checks. The AI didn't create these mistakes, and it didn't invent a new attack technique. What it did was help a single researcher sift through a huge amount of code for clues, fast. TechBooky points out that attackers can use the same tools, but so can defenders. The numbers also only describe the researcher's sample. They aren't an audit of every UK government service.

Amanda Brock, CEO of the nonprofit industry body OpenUK, doesn't blame open code. The Planning Inspectorate's problem, she says, was "internal housekeeping in the use of public tools." The data was exposed because a good process wasn't followed. "This is not an open source security problem."

The open code debate: locking it down won't fix it

For about a decade, the UK government has published taxpayer-funded code openly by default. That covers the Department of Health, the Home Office and local councils, among others. The goals are transparency and savings, since other bodies can reuse the code. But according to Wired, tight budgets have led several agencies to neglect maintenance and upkeep of their technology.

Now some are calling for less code to be published, because AI makes hunting for flaws much faster. The NHS reportedly told its tech teams in May to move away from open source code over exactly these security concerns.

Nesbitt-Smith thinks that's the wrong move. Hiding code without fixing the bugs first is the "worst-case scenario," he says. Researchers like him could no longer find the flaws. But attackers have probably copied the repositories already and would keep their access. On top of that, suddenly closing things off draws even more attention to the weak spots:

"If you don't fix all the problems, closing it is more likely to draw attention to you. It's like saying, 'Here be dragons, but please don't look.'"

TechBooky sees a more sensible response: scan repositories automatically for secrets like passwords and keys, keep permissions as narrow as possible, check who owns a record, and revoke exposed keys directly with the provider.

Our take

This case shows in very concrete terms what AI is changing in IT security. General-purpose language models make it cheap and fast to comb hundreds of repositories for careless mistakes. A well-meaning researcher can do that, and so can an attacker. The mistakes aren't new: forgotten credentials and missing permission checks are among the oldest problems in the industry. What's new is how little effort it takes to find them at scale. That shrinks the window agencies have to catch their own mistakes.

Some parts of the story are still fuzzy. The figure of more than 100 serious flaws comes from the researcher himself, and nobody has independently verified it. It's also unclear exactly how much of the work the AI did. On the plus side, the Planning Inspectorate noticed the access on its own and responded quickly. But the fact that such a dangerous key sat out in the open for 18 months shows where the real problem lies. Transparency is no substitute for maintenance. Public code needs the same rules as private code for handling credentials, testing, and reporting flaws. Even so, cases like this will likely make the debate over whether agencies should hide their code again even louder.