vulnerability
India's .bank.in Registry Leaked Credentials for 13 Months
2026-06-30
Earlier this year the Reserve Bank of India had what looked like a sensible idea. Force every bank in the country onto a dedicated .bank.in subdomain so ordinary customers could glance at a URL and tell a genuine bank from a knock-off. Thousands of banks signed up. The Institute for Development and Research in Banking Technology (IDRBT) got the job of running the registry.
Then someone actually looked at the portal.
33 endpoints, zero authentication
According to a disclosure from CashlessConsumer and researcher Srikanth L, the IDRBT registrar exposed its entire REST API across more than 33 unauthenticated endpoints. Anyone comfortable typing a curl command could pull:
- bcrypt password hashes
- mobile numbers
- email addresses
- login IP addresses
- device fingerprints
That data covered all 5,576 bank employees responsible for managing India's banking domains. The portal, the researchers say, went live without a proper security audit and ran without secured APIs for thirteen months.
The hygiene underneath isn't much better
While they were poking around, the researchers picked up some unflattering context about the namespace itself. Roughly 80 percent of the new .bank.in domains aren't using DNSSEC, the protocol that stops attackers from quietly redirecting DNS lookups. Around 40 percent have no DMARC record, which is what tells the world whether email claiming to come from a domain is legitimate.
A fair number of these bank domains are also running on shared hosting in the United States, Singapore and Lithuania, secured with free Let's Encrypt certificates. None of that is inherently terrible, but it is a long way from the image of a hardened, sovereign banking infrastructure that the scheme was sold on.
The point of the scheme was the opposite of this
IDRBT has reportedly fixed the exposed endpoints since the June disclosure. The Reserve Bank of India and the Indian government have, at the time of writing, said nothing publicly.
The awkward part is what the .bank.in namespace was for. It exists to make phishing and DNS spoofing harder. A trusted suffix is supposed to be a shortcut to confidence: see .bank.in, trust the page. A registrar leaking credentials and device fingerprints for the staff who administer those domains hands attackers exactly the material they need to do the opposite. Phish a few admins, log in from a familiar-looking device, push a DNS change, and the trusted suffix is now working for the wrong side.
Trust infrastructure needs the same scrutiny as the things it protects
There's a pattern here that keeps repeating: the systems built to anchor trust often get less security attention than the assets sitting behind them. Certificate authorities, domain registrars, identity providers, password managers. Each one is a single point of trust for thousands of downstream services, and each one is a disproportionately attractive target.
A trusted domain is only as trustworthy as the people and systems standing behind it. In this case, the people were doing their jobs. The system standing behind them was a REST API with the front door unlocked.