The domain meant to make Indian banks harder to fake spent more than a year with its own back door wide open.
In 2025, the Reserve Bank of India rolled out .bank.in, a restricted web suffix only verified banks could use, aimed at cutting down on phishing sites that mimic real banking portals. The idea was simple: if customers see .bank.in in the address bar, they can trust it. But the registry running that system, IDRBT, apparently wasn’t holding up its end.
Researcher Srikanth L of CashlessConsumer found that IDRBT’s portal exposed sensitive data belonging to all 5,576 employees who manage bank domains under the .bank.in system, according to a report later covered by The Register. The culprit was more than 33 API endpoints that required no authentication at all, so anyone who found the right URL could pull the data directly.
The open data included bcrypt-hashed passwords, email addresses, phone numbers, login IP addresses, and device fingerprints. The report also flagged over 1,000 orphaned super-admin accounts still sitting active in the system. The hashed passwords at least bought some protection. Anyone could read everything else as is.
No evidence confirms that anyone besides the researcher accessed the data during the roughly 13 months it sat exposed. But that’s arguably beside the point. These weren’t customer records. They were credentials belonging to the people who control which bank domains exist and where they lead.
Phishing or credential theft targeting them could have handed an attacker control over a domain the whole system aimed to protect.
The report also raises questions about how developers built the portal in the first place. IKCON Technologies won the contract without any competitive bidding, despite IDRBT’s own policy claiming the site had passed a vulnerability audit before launch.
The fix, once someone finally looked, took about two weeks. IDRBT received notice from CERT-In on June 8, 2026, and patched the issue by June 25. Neither IDRBT nor the RBI has commented publicly.
The .bank.in system still does what its designers intended. This incident just makes clear that a trust badge only holds up as well as the registry issuing it, and unauthenticated APIs remain a wide open door.
