UMANG's Security Flaw: EPFO, LPG and Aadhaar Data Sitting in Plaintext

The government's pitch for UMANG has always been convenience. One app, one login, every citizen service in one place. This week two security researchers reminded everyone what "one place" also means: one place for everything to leak from.

Here's what happened, what's actually at risk, and why — for once — this isn't a "you should have used a stronger password" story.

TL;DR

• Researchers Akshay C.S. and Viral Vaghela found multiple vulnerabilities in the UMANG platform.
• The flaws are architectural, not a single bad endpoint. Sensitive data was stored and served in plaintext across multiple services.
• Exposed: EPFO Universal Account Numbers (UANs), LPG cylinder booking details, and Aadhaar numbers — though the Aadhaar module itself was not the vulnerable component.
• An independent reviewer said the flaws could potentially let an attacker holding a UAN change the linked bank account and trigger a payout. No confirmed theft, but the capability was real.
• MeitY acknowledged it and says the plaintext APIs are now encrypted. The researchers say the fix can be bypassed.
• There is nothing users can do at the account level. The problem is the platform.

What is UMANG, and why does this matter

UMANG — Unified Mobile Application for New-age Governance — is the Indian government's single front door to citizen services. The idea is one app that aggregates thousands of central and state services behind one login: EPFO for provident fund, LPG gas booking, DigiLocker, PayGov, tax services, and more.

For most people, UMANG is the EPFO app. Checking a PF balance, raising a claim, activating a UAN — that's the daily-driver use case. And EPFO has been steadily pushing more into it: UAN activation and new UAN generation now happen through UMANG with Aadhaar-based Face Authentication.

So this isn't a niche app. It sits on top of the retirement savings of crores of Indians. Which is exactly why "broken by design" is not a phrase you want attached to it.

What the researchers found

The important detail for anyone technical: the researchers didn't report a single vulnerable endpoint. They looked at how the platform is stitched together and concluded the problem is structural.

The sensitive data — UANs, LPG booking records, Aadhaar numbers — was sitting in plaintext in the services around the core modules. Notably, the researchers said the Aadhaar module itself wasn't the flawed part; the data was leaking through the linked services that stored and passed it around without protection.

Viral Vaghela's summary was blunt: the platform is "broken by design." Not a regression, not a bad deploy — the way it was built.

If that pattern sounds familiar, it should. This is the same failure mode you see in a hundred internal apps: services trusting each other implicitly, sensitive fields persisted in the clear because "it's behind the gateway," and no threat model that treats the platform itself as the attack surface.

The EPFO angle: this is the part about your money

Data exposure is bad. Data exposure that touches a payout rail is worse.

Independent security researcher Karan Saini, who reviewed the findings at The Hindu's request, called the vulnerabilities "significant." His assessment of the worst case: an attacker in possession of UAN numbers could potentially change the bank account details linked to a PF account and initiate a payout — pulling money out to an account they control.

Two honesty caveats, because overselling this helps no one:

1. No theft has been confirmed. This is a described capability, not a proven heist.
2. Saini himself noted that rate limiting and the sheer size of the UAN pool make large-scale scraping of the database unlikely.

So: the lock was off. Whether anyone walked through the door at scale is unconfirmed. But "change the bank account and trigger a withdrawal" is a serious enough attack chain that the caveat doesn't make it comfortable.

The government's response

The Ministry of Electronics and Information Technology (MeitY) acknowledged the findings and said its development and security teams are implementing corrective and preventive measures. Specifically, the ministry stated:

• The plaintext data in the affected APIs has now been encrypted.
• It reviewed API transaction logs for the past three months.
• Transaction volumes looked normal.
• Monitoring for unusual activity is ongoing.

There's also a timeline detail worth noting. Soon after the researchers disclosed the issue to MeitY and CERT-In, EPFO took its portal offline for a "migration" and infrastructure upgrade. The official framing was a planned database consolidation. No authority has confirmed any link between the disclosure and the migration, and the Ministry of Labour declined to comment. Draw your own conclusions.

Why the fix is being questioned

This is where it gets uncomfortable. The researchers say the remediation isn't enough. Akshay C.S. claimed a simple workaround can bypass the new encryption.

If that holds, then encrypting the fields is treating the symptom. When the underlying design assumes trust it hasn't earned, wrapping a few API responses in encryption doesn't fix the architecture — it just adds a step for the attacker.

What users can actually do (not much)

This is the frustrating part, and the honest one. There is no user-side fix. As Akshay put it, the leak is within the portal itself, caused by a design flaw. Follow every security best practice you like — the exposure exists at the platform level, not because of anything you did.

What you can do is stay alert:

• Log into your EPFO account and confirm the bank account linked to your UAN is still yours.
• Set up the missed-call / SMS balance check on your registered mobile number so any movement pings you fast.

That doesn't fix the platform. It just means you find out quickly if something is wrong.

Who found this

Worth knowing, because these two have a track record. Akshay C.S. and Viral Vaghela are the same duo who uncovered a large data leak at Apollo Hospitals, one of India's biggest hospital chains — an exposed archive plus SQL injection flaws, signs of reverse shells, and weak authentication. They followed the same responsible-disclosure path there: report to the organisation, then escalate to CERT-In and NCIIPC.

Viral works in offensive security, red teaming, and vulnerability assessment, and writes up his research publicly. Karan Saini is the independent researcher who reviewed the UMANG findings for The Hindu and provided the payout-risk assessment.

This is the unglamorous work of poking government infrastructure so citizens' money and identity data don't quietly walk out the door. It doesn't get thanked enough.

The builder takeaway

Strip away the government angle and this is a lesson every engineer building a platform should internalize:

• Plaintext at rest is not a shortcut. It's a liability you ship to production.
• One aggregation layer over many services concentrates risk. The convenience that sells the product is the same property that makes a single design flaw catastrophic.
• Threat-model the platform, not the endpoint. "It's behind the gateway" is not an authorization model.
• Encrypting a response is not the same as fixing the design. If the workaround survives the patch, you patched the wrong layer.

Build the walls before you bolt on the hundredth service. UMANG is what happens when you don't.

Sources

• The Hindu — original investigation (primary source).
• Medianama — Researchers find security flaws in UMANG
• Digit — Using UMANG app? Your data might be exposed to hackers
• BOOM Live — Apollo Hospitals data leak (researcher background)
• Republic World — EPFO portal offline / migration context