A government credential removed from a GitHub branch remained publicly retrievable for 18 months—and still worked.
That exposure was among the findings highlighted in a Nov. 10 WIRED report on ControlPlane researcher Chris Nesbitt-Smith’s examination of UK public-sector code. He reported more than 100 serious vulnerabilities after scanning 349 codebases across 33 organizations, with weaknesses in roughly two-thirds of those examined.
For security teams, the published disclosures offer specific lessons about revoking exposed secrets, limiting application permissions, and checking who can change a record. The findings describe the researcher’s sample, rather than a government-wide vulnerability rate. The highlighted issues have since been addressed.
A deleted file left a live credential behind
In its Planning Inspectorate disclosure, ControlPlane says an exported Azure Synapse notebook contained a complete Microsoft Entra ID application credential. The integration needed to retrieve an HR file from SharePoint, but its permissions extended across the tenant’s SharePoint sites and employee OneDrive accounts.
Removing the file from the branch did not invalidate the credential. An orphaned commit remained accessible through GitHub’s raw-content infrastructure, according to the researchers.
ControlPlane says it verified access using metadata and a write-permission check designed to fail without changing data. The agency revoked the secret approximately 20 minutes after receiving the report on Aug. 26.
The Planning Inspectorate told WIRED its monitoring had already detected the researcher’s activity and that it verified no data breach occurred. Potential access should therefore be distinguished from confirmed theft.
The case combines three failures: publishing a secret, granting an integration more access than it needed, and leaving that access usable after repository cleanup. Similar risks appeared in research on AI companies leaking secrets on GitHub, including credentials hidden in deleted forks and developer repositories.
Other disclosures show different access-control failures
The published cases extend beyond repository credentials. ControlPlane’s reports describe weaknesses in browser-delivered code, procurement forms, and account linking:
| Service | What ControlPlane found | Reported resolution |
| Scottish Government open data portal | A long-lived administrator token embedded in public JavaScript could expose administrative account information and allow configuration changes. | The owner permanently decommissioned the service after determining it was no longer needed. |
| Department for Education’s Get Help Buying for Schools | Someone holding a valid request identifier could change request details, including the contact email, and submit the request without signing in. | Record access and related actions were tied to the active session. |
| Department for Education’s teacher application service | Account-linking code could overwrite an existing login association without rejecting a conflicting identity. | A check was added to reject conflicting associations. |
These findings and resolutions are documented in ControlPlane’s individual disclosures.
The Scottish portal disclosure illustrates why a build-time environment variable does not keep a secret private when its value is compiled into JavaScript sent to browsers. An administrator credential shipped that way becomes available to visitors.
That exposure resembles the broader problem of hardcoded secrets in downloadable Android apps: material distributed to users can also be inspected by attackers.
The school procurement finding involved a different mistake. A long, random request identifier effectively served as permission to change the record. The department fixed the issue on July 10, according to ControlPlane.
The teacher account-linking report carries an important limitation. Testing linked a new sign-in to the researchers’ own account; it did not demonstrate a separate account-takeover route or replace another applicant’s login. The disclosure describes a risk identified in code and a subsequent correction.
What security teams should verify now
The immediate response to an exposed credential should happen at the service that issued it. GitHub’s remediation guidance puts revocation or rotation first, before any decision to rewrite repository history.
Security and engineering teams should use these disclosures to check four areas:
- Credential validity: Confirm that every previously exposed password, token, or application secret has been revoked or rotated. A closed repository alert or deleted file does not establish that access has ended.
- Application permissions: Compare each integration’s access with its actual task. A workflow reading one HR file should trigger scrutiny if it can write across unrelated sites and employee storage.
- Public build artifacts: Inspect production JavaScript, exported notebooks, and downloadable packages for embedded secrets. Include release artifacts alongside source-code checks.
- Record ownership: Test whether changing a request identifier lets one session read or modify another session’s record. Review guest workflows and account-linking conflicts explicitly.
Prioritize credentials that remain valid and can reach sensitive systems, then investigate their use through available identity and service audit logs. Record any gaps in historical log coverage so the incident assessment reflects what can actually be established.
The Google DevSite flaw involving an exposed authentication secret shows how a leaked secret can combine with another weakness to create a more damaging attack path. Remediation should therefore include both the credential and the application behavior that trusted it.
For the next review, ask teams to demonstrate that an old exposed credential fails, an integration cannot access unrelated resources, and a record rejects requests from an unauthorized session. Those checks provide evidence that the underlying access has changed.
Read more: Exposed secrets and weak access controls also featured in an operation targeting public services. Learn how one hacker used 12 AI agents to target Taiwan’s emergency services and what defenders can learn from the findings.