A security researcher has uncovered more than 100 serious vulnerabilities in publicly available UK government code, including credentials that could have given an attacker read-write access across an entire public body’s Microsoft 365 estate. The findings, first reported by WIRED, have reignited a long-running Whitehall debate: should government keep publishing its code at all?
ControlPlane researcher Chris Nesbitt-Smith examined 349 public-sector codebases belonging to 33 organisations and found serious weaknesses in roughly two-thirds of them. The problems were familiar ones – exposed credentials, missing access checks, overpowered service accounts and insecure defaults. What made the exercise notable was the toolkit: consumer versions of Anthropic’s Claude Opus and Sonnet models, run from a laptop. Nesbitt-Smith has stressed that many of the issues could have been caught by a routine IT health check. All of the issues highlighted have since been disclosed to the organisations involved and addressed.
For Olly Maxwell, principal security operations analyst at Huntress, the story is depressingly recognisable. “Having transitioned from Foreign, Commonwealth & Development Office security to tracking EMEA threat actor tradecraft at Huntress, the recent WIRED report on public sector vulnerabilities strikes a very familiar chord,” he said. “Whenever stories like this break, the immediate political reflex across Whitehall is to lock down repositories and abandon transparent coding practices. That reaction fundamentally misunderstands both the root cause of the exposure and the reality of the modern threat landscape.”
A “god-tier” key left in the history
The most serious case involved the Planning Inspectorate, the agency that handles planning appeals and national infrastructure casework in England. An exported Azure Synapse notebook pushed to a public GitHub repository contained a complete Microsoft Entra ID application credential. The integration it served only needed to retrieve a single HR file from SharePoint, but the permissions attached to it reached across every SharePoint site in the tenant and into private employee OneDrive accounts – including libraries holding evidence for statutory planning inquiries under legal hold.
Maxwell is clear about where the blame lies. “Exposing tenant-wide Microsoft Entra ID credentials in a public GitHub repository is not a byproduct of open source philosophy. It is a severe breakdown in basic supply chain governance and DevSecOps hygiene.”
Collin Hogue-Spears, senior director of solution management at Black Duck, points to the permissions model as the factor that turned a leaked secret into a potential catastrophe. “This is mostly the result of a failure to implement least privilege and implicit trust controls. Excessive permissions are what made the Planning Inspectorate leak dangerous: ControlPlane found that a pipeline needing one file had write access to every SharePoint site and to OneDrive.”
He added that the pattern is far from isolated: “Broad application permissions have amplified other incidents this year: in October, Huntress confirmed unauthorised sign-ins in at least 162 Microsoft 365 tenants through one compromised backup-application credential. An application credential signs in with no user and no second factor. Microsoft Entra ID treats whoever holds the secret as the application.”
Deleted from the branch, not from the identity provider
Crucially, the credential had been removed from the repository’s branch – but not revoked. An orphaned commit remained retrievable through GitHub’s raw-content infrastructure for around 18 months, and the secret still worked. The Planning Inspectorate said its monitoring detected the researcher’s activity, that it treated the report as a cyber incident and revoked the credential roughly 20 minutes after receiving it on 26 August, and that it found no evidence of a data breach.
“A force push removes the file from the branch, not the secret from Microsoft Entra ID,” said Hogue-Spears. “When a researcher used the secret 18 months after the force push, the Planning Inspectorate’s monitoring flagged the activity, and the agency revoked the secret about 20 minutes after the report.”
Ronald Lewis, head of cybersecurity governance at Black Duck, argues that the episode exposes a design assumption rather than a coding slip. “This is a classic example of security being built, at least in part, on obscurity. The problem isn’t that the code was public, and it’s easy to point at AI as the culprit. Realistically, this isn’t an AI problem or an open-source problem. It’s a security architecture problem. The organisation implicitly relied on the assumption that these weaknesses, credentials, and excessive permissions wouldn’t be discovered. AI simply made discovering them faster and cheaper.”
AI changes the economics, not the mistakes
The use of off-the-shelf AI has inevitably drawn headlines, and it lands in a year in which the UK government has itself leaned on frontier models to hunt for flaws. In June, the Government Cyber Coordination Centre published results from internal hackathons that surfaced 407 findings across public repositories in nine departments, and in October an AI-assisted discovery of critical PHP vulnerabilities forced dozens of public sector sites offline.
Maxwell believes the Nesbitt-Smith findings should change how defenders model the threat. “The fact that a researcher identified over 100 serious flaws across dozens of public bodies using consumer grade AI on a laptop should serve as a wakeup call regarding threat asymmetry. AI did not introduce these vulnerabilities, but it has completely democratised the cost of discovering them,” he said.
“Public code repositories are subjected to continuous, automated scraping by hostile state nexus groups and initial access brokers. If an independent researcher can surface these gaps trivially, the operational assumption must be that adversaries have already mirrored the repositories and harvested the exposed key material.”
Hogue-Spears points to evidence that this is already happening at scale. “Attackers search public code for application secrets. In a separate campaign Microsoft reported on November 5, threat actors used an agentic AI framework to search GitHub for secrets, often by organisation name, and then signed in as the exposed applications.”
And the danger, Maxwell warns, is not necessarily immediate. “Crucially, highly capable threat actors do not always exploit this access immediately. They bank valid administrative keys and quietly establish strategic persistence within environments like SharePoint or legal hold libraries, holding that access until it becomes geopolitically or financially advantageous to strike.”
Lewis echoes the point that AI is an accelerant rather than a cause. “‘Security by obscurity’ as a design choice is dangerous in the age of AI, but AI isn’t the root cause. An important takeaway for businesses is that ‘hard to find’ can no longer be treated as a security control. Organizations should assume that anything exposed to the internet, including source code, APIs, configurations and credentials, will eventually be analysed by AI. The barrier to doing that kind of analysis is rapidly disappearing.”
Rushed delivery and deferred security
Government has defaulted to publishing the code it produces with public money for around a decade, on the grounds that it improves transparency and makes reuse cheaper. But funding pressure has left many departments struggling to maintain their technology estates – and much of the build work is outsourced.
“The rapid push to modernise government digital services relies heavily on third party systems integrators and outsourced development,” said Maxwell. “When aggressive delivery milestones collide with public sector funding squeezes, foundational security controls like automated secret scanning and identity posture management are routinely treated as deferred technical debt. The procurement lag for security tooling frequently eclipses the operational lifecycle of the product itself.”
“These exposures happen because code is rushed into production environments before proper governance and risk compliance principles are applied. Securing modern CI/CD pipelines requires specialized knowledge to enforce pre commit security gates and token lifecycle management. Without those guardrails natively embedded into the developer workflow, credential sprawl is inevitable.”
Lewis agrees that the answer lies in the basics. “Another important note is that this highlights the need for getting the fundamentals right. Secrets shouldn’t live in source code. Credentials should be short-lived and rotated. Identity should follow least privilege. A compromised credential shouldn’t provide broad access across the enterprise. And organisations need automated controls in the development pipeline that can identify these problems before code is published or deployed.”
For Hogue-Spears, that means removing long-lived secrets from pipelines altogether. “Security leaders must move pipelines to managed identities or workload identity federation, which leave no secret to commit. A managed identity keeps whatever permissions an administrator grants it, so replace tenant-wide Microsoft Graph permissions with selected permissions scoped to the site or file the application needs. Treat any secret that reaches a public repository as compromised and revoke it in the identity provider before anyone cleans the Git history.”
Beyond leaked credentials
Not every finding involved a secret. At the Department for Education, the Get Help Buying for Schools service allowed anyone holding a valid request identifier to change request details – including the contact email – and submit the request without signing in; it was fixed on 10 July. In the department’s teacher application service, an account-linking code could overwrite an existing login association. Elsewhere, a long-lived administrator token was found embedded in public JavaScript on a Scottish Government open data portal, which has since been decommissioned.
Hogue-Spears highlighted a further DfE case as a lesson in authorisation testing. “In the Department for Education’s training-provider register, delete actions ran with no authorisation check, so a low-privileged staff account was able to soft-delete registered providers and other staff accounts. The same service’s user-editing policy did run, and it examined the record’s state, not the caller’s role, so a standard staff account was able to deactivate an administrator’s account. The department fixed both flaws in July. If your tests never sign in as an ordinary user and attempt an administrator’s action, a missing check and a wrong check both ship.”
Why closing the code won’t close the gap
The findings arrive as some in government question whether public bodies should keep repositories open in an era of AI-accelerated discovery. Nesbitt-Smith himself has warned that pulling code private without fixing the flaws could make risks harder to spot. The experts are unanimous on this point.
“Making a repository private hides the code, and a secret that leaked while the repository was public stays valid until it expires or someone revokes it,” said Hogue-Spears. “Leaders have to name an owner for every public repository. Since May, the UK government guidance has set a minimum before code goes public: a named owner and controls that stop developers from committing secrets.”
Maxwell is blunter. “Consequently, advising departments to pull their codebases private without remediating the underlying architectural flaws is incredibly dangerous. Security by obscurity has never stopped an advanced persistent threat. Closing the repositories simply blinds the independent research community that provides vital early warnings, while doing absolutely nothing to evict threat actors who already hold the compromised credentials.”
Lewis argues the real shift is in mindset. “Although there’s a knee jerk to blame AI for discovering weaknesses like this; in reality, a motivated attacker could have found these. AI doesn’t make design decision more dangerous; it simply changes the economics. In short, AI allows someone to search for existing mistakes, just faster, cheaper and at a scale that wasn’t practical in the past. And perhaps the most important lessons learned from this is that businesses need to operate under the assumption that if a weakness is discoverable, someone will eventually find it.”
Maxwell leaves the final word with a call for discipline rather than retreat. “We operate in a climate where the UK faces continuous, hostile cyber activity. There is a vast difference between falling victim to a highly sophisticated zero day exploit and simply handing adversaries your production logins. The government does not need to retreat into the shadows. It needs to mandate strict, automated security gates across the entire software supply chain and treat identity security with the rigorous operational discipline it demands.”
