VULNpocalypse
MediumVulnerabilityMonitoring

Researcher says 100+ flaws found in UK government public code, per Wired

Wired reports a researcher says he found over 100 vulnerabilities in public UK government code; check your repos for committed secrets.

Published
Exploitation
No confirmation of exploitation; the Planning Inspectorate told Wired it verified that no data breach occurred

What happened

According to Wired, security researcher Chris Nesbitt-Smith of ControlPlane says he found more than 100 serious vulnerabilities in publicly available UK government code. Wired reports that he scanned 349 public sector codebases across 33 organizations and says he found vulnerabilities in around two-thirds of them. Wired says he used Claude Opus and Sonnet models on a consumer-grade laptop, and quotes him as saying many of the issues could have been caught by a routine IT health check. These figures are the researcher’s own, as reported by Wired. We found no independent verification of them in the sources.

Wired reports that the most serious case involved the Planning Inspectorate, which handles land-use matters across England. According to Nesbitt-Smith, the agency accidentally committed a login to a public GitHub repository and had not fully removed it. He says the credentials, a Microsoft Entra ID, would have given “god-tier” read and write access to all SharePoint sites and private employee OneDrive accounts, including HR records. He also says they would have reached libraries holding evidence under legal hold for planning inquiries and appeals. He further says the credentials seemingly did not expire.

A Planning Inspectorate spokesperson told Wired that its monitoring tools detected the researcher’s activity in August and that it was already handling this as a cyber incident when ControlPlane made contact. The spokesperson said the agency fixed the issue within 20 minutes of the report and verified that no data breach occurred. Wired also reports, citing Nesbitt-Smith, findings in Department of Education code (a schools procurement service, a teacher application service and the register of training providers and apprenticeships) and in a Scottish Government open data portal. Wired says the organizations have since dealt with the issues.

Not confirmed in the sources: the exact list of affected repositories, the individual vulnerability details, any CVE identifiers, and whether anyone other than the researcher accessed the exposed credentials.

Am I affected?

The sources name specific UK public bodies, not a product or version. You are most likely to be affected if you maintain public repositories, in government or elsewhere, and any of these apply:

  • A credential, token or key may have been committed to a repository at some point.
  • A public repository or its deployed service has no clear owner or patching route.
  • A repository was made private after publication. Wired quotes Nesbitt-Smith as saying adversaries may already have mirrored such repositories. The GOV.UK guidance says closing code after publication may not remove exposure.

If you are one of the organizations named by Wired, the sources say the issues have been dealt with. Confirm this with your own security team.

What to do now

  1. Search your public and private repositories, including history, for committed secrets such as credentials, API keys, tokens and private keys. The GOV.UK guidance says secrets should never be committed to any repository, public or private.
  2. Enforce controls that prevent secrets being committed, and enable vulnerability and secret scanning plus dependency update tooling, as the GOV.UK guidance lists among its minimum standards.
  3. Make sure each public repository has a named owner, a security contact and a defined route for reporting vulnerabilities, per the same guidance.
  4. Set agreed timelines for patching critical and high vulnerabilities, and mark and archive unmaintained repositories, or give any deployed service an explicit owner and patching route. This also comes from the GOV.UK guidance.
  5. Do not rely on making code private as a substitute for fixing weaknesses. The guidance states that closure is not an appropriate mitigation for lack of ownership or patching, and Nesbitt-Smith tells Wired that closing code without fixing the problems is the “worst case scenario”.

Sources