Security Review Finds More Than 100 Flaws in UK Public Sector Code

More than 100 vulnerabilities across UK public sector codebases point to a practical security problem: exposed credentials and basic weaknesses can leave sensitive services at risk when routine maintenance falls behind. The findings also show that AI tools can help researchers find flaws, though the researcher involved says many of these issues could have surfaced in an ordinary technology health check.

Chris Nesbitt-Smith, a security researcher at ControlPlane, examined 349 publicly available codebases belonging to 33 organizations. He reported vulnerabilities in around two-thirds of them. The issues affected services used by departments and local authorities, including systems containing personal information and tools that support education and planning.

The UK has published code produced with public money for about a decade, with transparency and reuse among the reasons for the practice. But departments have also faced funding pressures that can leave older technology without adequate maintenance. Nesbitt-Smith used consumer-grade versions of Anthropic’s Claude Opus and Sonnet models on a laptop to help identify problems. He told WIRED that the flaws were mostly unsophisticated and could have been caught through routine checks.

A credential with broad access

The most serious issue involved the Planning Inspectorate, which handles land-use matters in England. A login credential had been accidentally committed to a public GitHub repository, and the organization had not fully removed the associated access. The credential appeared not to expire and could have enabled broad access across Microsoft Entra ID.

According to Nesbitt-Smith, that access included read and write permissions for SharePoint sites and private employee OneDrive accounts, potentially reaching human resources records. It also extended to libraries holding evidence for statutory planning inquiries and appeals. The combination of a publicly exposed credential and its extensive permissions could have enabled data theft or encryption, he said.

The Planning Inspectorate told WIRED that its monitoring tools detected Nesbitt-Smith’s activity in August and that it was already treating the matter as a cyber incident when ControlPlane contacted it. The organization said it fixed the weakness within 20 minutes of receiving the report and verified that no data breach had occurred. It also said it had reviewed and strengthened its systems and processes.

The case illustrates why a secret can remain dangerous even after someone discovers it: deleting a visible copy does not necessarily revoke the access it grants. The response needs to cover the credential itself, its permissions, and any places where it may have been copied. Here, the credential’s scope made the exposure especially serious.

Flaws across education and data services

Other findings affected services associated with the Department for Education. They included a school procurement service, a teacher application service holding personal details, qualifications, employment histories and identity documents, and England’s register of training providers and apprenticeships.

Nesbitt-Smith also found a weakness in a Scottish open data portal. It could have let visitors read administrative account information and alter the site’s configuration. The organizations involved have since addressed the reported issues.

The range of affected services matters because repositories are often only one part of a larger system. A weakness in an application can expose data or allow changes even when the code is public for legitimate reasons. The findings described here concern security practices around credentials, permissions and application behavior; they do not show that publishing code itself caused every flaw.

Closing repositories does not repair systems

Some have argued that public sector organizations should stop publishing source code because AI models can speed up vulnerability discovery. The NHS reportedly directed technology teams to move away from open source code in May amid concerns about AI-assisted security research.

OpenUK chief executive Amanda Brock said the Planning Inspectorate exposure stemmed from poor internal handling of a credential, rather than from open source development. That distinction is useful: hiding a repository may make a flaw harder for outside researchers to spot, but it does not revoke a leaked login or correct unsafe permissions.

Nesbitt-Smith argued that withdrawing code without fixing the underlying weaknesses could make matters worse. Repositories may already have been copied, so removing public access does not ensure that other parties have lost access to the code. A sudden closure can also draw attention to a system without resolving its exposure.

For organizations that publish code, the findings make a case for pairing transparency with basic operational controls: checking repositories for secrets, revoking credentials that escape, limiting permissions, and maintaining the systems connected to the code. AI-assisted discovery can make review faster, but the reported flaws suggest that consistent maintenance and response still determine whether exposed code becomes an exploitable path into sensitive systems.