Government code flaws exposed sensitive data risks in the UK and India

Security researchers have uncovered serious flaws in publicly available government code and digital platforms in both the UK and India, exposing how routine public-sector software maintenance can put sensitive personal and administrative data at risk.

The UK case, reported by WIRED, found more than 100 serious vulnerabilities in public government code, including a Planning Inspectorate repository that left login credentials exposed on GitHub. In India, MediaNama reported vulnerabilities in the UMANG platform’s underlying architecture that could expose data across connected services, including EPFO details, LPG booking records and Aadhaar numbers stored in plaintext in some services.

What the researchers found

The two investigations point to different technical failures, but the same operational problem: public agencies are handling code, credentials and APIs in ways that can widen the blast radius of a mistake. In the UK, the findings came from a scan of public-sector codebases. In India, researchers focused on the architecture behind a platform that connects multiple government services through integrated APIs.

UK government code: widespread vulnerabilities, exposed credentials

WIRED reported that a researcher found more than 100 serious vulnerabilities in publicly available UK government code. Across 349 public-sector codebases scanned at 33 organizations, roughly two-thirds were said to contain vulnerabilities.

Among the cases highlighted was the Planning Inspectorate, which reportedly left login credentials in a public GitHub repository. That exposure created what the report described as a high-risk access path. According to WIRED, the exposed Microsoft Entra ID could have granted read and write access to SharePoint and employee OneDrive accounts, including human resources records.

Other examples cited by WIRED widened the picture. Code associated with the Department for Education reportedly included flaws in systems used for procurement, teacher applications and training providers. The Scottish Government’s open-data portal, meanwhile, reportedly contained a flaw that could have exposed admin account information and controls over site configuration.

Those findings matter because they suggest the problem is not confined to one department or one type of system. They span identity management, content platforms, administrative portals and application workflows — the kinds of services that often sit at the center of government operations.

India’s UMANG platform: architecture under scrutiny

MediaNama reported a separate set of vulnerabilities in UMANG, India’s government mobile platform that aggregates access to public services through linked APIs. The reported exposure included EPFO universal account numbers, LPG booking details and Aadhaar numbers stored in plaintext in some services.

According to MediaNama, the Ministry of Electronics and Information Technology said it was implementing corrective and preventive measures. The ministry also said plaintext API data had been encrypted and that transaction logs for the previous three months looked normal.

Researchers, however, disputed whether the fixes were enough. MediaNama reported that they said a workaround could still bypass the new encryption. Independent reviewer Karan Saini called the flaws significant and warned they could potentially be abused to change bank details and initiate payouts.

The researchers said they had reported the UMANG flaws to MeitY and CERT-In. EPFO took its portal offline soon after, though officials did not confirm a link between the outage and the disclosure.

Why it matters

This is not just a story about software bugs. It is a story about public trust, identity systems and the basic discipline of protecting access to state infrastructure.

In the UK, the reported weaknesses show how even publicly shared code can become dangerous when credentials, admin controls or cloud permissions are left exposed. Microsoft Entra ID, as the fact sheet notes, can govern access to SharePoint and OneDrive. That means a single credential mistake could reach internal documents, HR records or other sensitive files.

In India, the concerns are broader because UMANG is a gateway platform. If a flaw exists in the underlying architecture, the risk can extend across multiple linked services rather than staying inside one application. That makes fixing one layer of the stack less reassuring unless the surrounding APIs and data handling are also hardened.

For readers, the immediate implication is simple: government services increasingly depend on cloud identity systems, APIs and shared code repositories. When those systems are poorly managed, the exposure is not theoretical. It can touch payroll data, account records, administrative controls and other information that people assume is sealed off from public view.

For the market and the wider public sector, the reporting is also a reminder that transparency and security can collide. Governments publish code for reuse, cost savings and openness. But open repositories can also surface credentials and misconfigurations if teams do not separate public source from private secrets.

How did this happen?

The immediate answer, according to the reporting, is poor operational hygiene. The deeper answer is that public-sector software stacks are often assembled from many moving parts: source repositories, cloud identity systems, shared APIs, portals and third-party services. Each layer can fail independently, but the damage often compounds.

Open code without secure process

OpenUK argued that the Planning Inspectorate case was a process failure rather than an open-source problem. Amanda Brock, the group’s chief executive officer, said, “That’s not an open source security issue.”

That distinction matters. Public code publication is not itself the issue; the issue is what gets published with it and what controls surround it. If credentials, access tokens or configuration details make it into a public repository, the visibility that should support trust instead creates risk.

Chris Nesbitt-Smith, the ControlPlane security researcher quoted by WIRED, warned that shutting repositories after a discovery may not solve the underlying problem. “The option for ransomwaring them, for encrypting all the data, or just stealing all the data, was abundantly there,” he said. He also cautioned that closing repositories without first fixing the flaws could remove visibility for researchers while attackers may already have copied the material.

That warning is important because it highlights the asymmetry in public-code exposure: once a secret is public, anyone can mirror it. Closing the repository later may limit future discovery, but it does not rewind what was already exposed.

Architecture risks in India’s government platform

The UMANG reporting suggests a different but related problem. A platform that aggregates services through integrated APIs can become a single point of failure if one weak layer reveals data from several departments at once.

MediaNama’s report pointed to exposure across linked services, including EPFO and LPG booking details and Aadhaar numbers in some plaintext services. That is a reminder that modern government apps rarely stand alone. They often sit on top of a maze of back-end systems with uneven security practices.

Viral Vaghela’s assessment, as reported by MediaNama, was blunt: “Almost everything is broken by design.” Even allowing for the sharp wording, the point is clear enough. If systems are built with fragmented controls, weak API protections and lingering plaintext handling, vulnerabilities can persist even after a fix is applied at one layer.

By the numbers

Background: how we got here

Public bodies have been publishing code publicly in the UK for around a decade, according to the fact sheet, for transparency, reuse and lower development costs. That model can be useful. It allows outside scrutiny, helps reuse of common tools and can reduce duplication across agencies. But it also demands a disciplined approach to secrets management, cloud access and repository hygiene.

The reported flaws appear against a broader backdrop of recurring concern about exposed credentials and data leaks. MediaNama noted that in June 2025, CERT-In warned about 16 billion surfaced login credentials. The same outlet also pointed to a July 2026 report about more than 1,000 databases being sold, part of a broader pattern of data exposure.

Within that context, the UK findings look less like an isolated embarrassment and more like one example of a longstanding failure mode: organizations publish code and build integrations faster than they harden the systems around them. The result can be a mismatch between the visibility of the software and the invisibility of the secrets inside it.

The Indian case adds another layer to that history. UMANG is designed to bring services together through a single interface. That convenience is useful to citizens, but it can also concentrate risk. If the architecture behind the platform is weak, many services can inherit the same exposure path.

What the agencies said

In the UK, the Planning Inspectorate said it detected the activity immediately in August and fixed the issue within 20 minutes. The agency said no data breach occurred and that its systems and processes were strengthened afterward.

That response suggests a rapid containment effort. But it also leaves unanswered questions about whether the exposure was limited by good fortune, by fast detection, or by the absence of malicious follow-through. The fact sheet does not indicate that data was stolen, only that the potential access existed.

WIRED also reported that OpenUK framed the Planning Inspectorate case as a process failure rather than a security problem inherent to open source. That argument may resonate with public bodies that want to preserve open-code practices without conflating openness with weakness.

In India, MeitY said it was implementing corrective and preventive measures. It also said plaintext API data had been encrypted and that the last three months of transaction logs looked normal. Researchers disputed the sufficiency of those fixes and said the workaround they identified could still get around the new encryption.

That disagreement is important because it shows the difference between a patch and a full remediation. A ministry may say the visible hole is covered. Researchers may still see a path around it. Until both sides agree the architectural issue is closed, the underlying risk remains unsettled.

What happens next?

The most immediate question is whether all affected UK repositories have been reviewed and whether any other departments or local authorities remain exposed. The fact sheet says WIRED’s scan covered 33 organizations, but it does not identify every body still at risk after the reported fixes.

Another open question is whether repositories have been closed or restricted because of these findings. Nesbitt-Smith’s warning suggests that doing so too quickly could make life harder for researchers while doing little to slow attackers who already copied the material.

In India, the key question is whether the UMANG issues have been fully fixed. The reported encryption change may be an improvement, but researchers say a workaround still exists. If that is correct, the platform may still be vulnerable even after the ministry’s stated corrective measures.

There is also uncertainty around EPFO’s portal downtime. Officials did not confirm that the outage was tied to the disclosure, so it remains unclear whether the shutdown was precautionary, coincidental or part of routine maintenance.

Finally, there is the hardest question of all: whether any of the exposed data was actually abused. Neither report provides evidence of confirmed exploitation. But in public-sector security incidents, the gap between exposure and abuse can be hard to measure, especially when the exposure is brief or the systems involved are widely connected.

What to watch

• Whether the UK government identifies additional codebases with exposed credentials or admin controls.
• Whether agencies change how they publish source code and manage secrets in public repositories.
• Whether MeitY or CERT-In provide a fuller technical explanation of the UMANG fixes.
• Whether researchers can verify or refute the reported workaround around UMANG’s new encryption.
• Whether EPFO gives a clear explanation for the portal outage and any link to the disclosure.

The bigger picture

These cases show how public-sector security failures often start with mundane mistakes: a credential left in a repo, a weak API control, an exposed admin setting, a plaintext field that should never have existed in the clear. The consequences can still be serious because government platforms sit on top of sensitive citizen data and essential services.

The reporting also shows a split in perspective. Security researchers tend to focus on what could have happened if an attacker had acted first. Agencies often focus on whether they detected and contained the issue quickly. Both views matter. One describes the vulnerability; the other describes the response.

For readers, the lesson is not simply that governments have been hacked or nearly hacked. It is that data exposure can emerge from the ordinary way public systems are built and maintained. If code, APIs and credentials are not governed with the same care as the services they support, transparency can become a liability instead of a safeguard.

And because these are public systems, the pressure to get them right is higher than usual. Citizens cannot opt out of tax portals, benefit platforms, planning systems or identity-linked services. That is why even a short-lived exposure — one detected in August and fixed in 20 minutes, or one disputed soon after disclosure — deserves scrutiny beyond the initial headline.

The next round of answers will determine whether these incidents become isolated warnings or evidence of a wider problem in how public-sector software is published, connected and protected.

Source split: what the outlets emphasized

WIRED focused on the UK side of the story, highlighting the scale of the code scan, the Planning Inspectorate repository, and the possibility that exposed Microsoft Entra ID credentials could have opened access to SharePoint and OneDrive records. MediaNama concentrated on India’s UMANG platform, stressing the architecture of linked services, the plaintext exposure allegations and the dispute over whether MeitY’s fixes fully closed the gap.

Read together, the reports describe the same underlying risk in different forms: when public systems are built on shared code and linked services, small mistakes can spread far beyond the original repository or API call.