India built a domain to make its banks harder to fake. In 2025 the Reserve Bank of India mandated .bank.in, an exclusive namespace that only verified banks can use, as a trust signal meant to blunt the phishing and fake-website fraud that plagues Indian banking. In late June, the registry that runs it demonstrated the other side of that bargain. For roughly 13 months, the portal operated by IDRBT, the exclusive registrar for .bank.in, exposed the data of the 5,576 bank employees who administer those domains through more than 33 unauthenticated API endpoints, according to a report by researcher Srikanth L of the consumer collective CashlessConsumer and reporting by The Register.
The Domain That Was Supposed to Signal Trust
The .bank.in namespace exists precisely because domains are a front line for banking fraud. Customers are trained to check the address bar, and attackers respond with lookalike domains that mimic a bank’s real site. By reserving .bank.in for verified institutions, the RBI intended the suffix itself to be a mark customers could rely on, with IDRBT, a Hyderabad-based banking-technology institute, as the single body that handles registration and issues the domains. That design concentrates a great deal of trust in one registry. Everyone who manages a bank’s .bank.in presence holds an account on IDRBT’s portal, which makes that portal a high-value target.
What the Portal Left Open
The failure was a common one. The registrar’s backend exposed more than 33 REST API endpoints that required no authentication, so anyone who knew the URLs could query them directly. According to the CashlessConsumer report, the exposed data covered all 5,576 administrators and included:
- Bcrypt password hashes
- Email addresses
- Mobile numbers
- Login IP addresses
- Device fingerprints
The same report found more than 1,000 orphaned super-admin accounts. The passwords were hashed with bcrypt rather than stored in plaintext, which makes them expensive to crack, and there is no public evidence that anyone beyond the researcher accessed the data. The rest of the fields, however, were readable as they stood, and stayed that way for 13 months.
The report also questions how the portal was built. It was awarded to a single vendor, IKCON Technologies, with no tender or competitive process, and IDRBT’s own security policy had assured users the site was “audited for known application-level vulnerabilities before the launch.” That assurance is hard to square with endpoints that sat exposed for more than a year.
Why a Registry Leak Is Not an Ordinary Data Leak
What makes this more than an ordinary data leak is who was exposed. These were not customers but the administrators who control which .bank.in domains exist and where they point. The directly readable fields, emails, phone numbers, IP addresses and device fingerprints, are exactly what a targeted phishing campaign against those administrators would need. Had an attacker cracked a hash or phished a credential during the exposure window, the theoretical prize was control of a bank-domain account, and with it the ability to tamper with the domains that system was built to keep trustworthy. A registry compromise erodes the .bank.in guarantee at its root.
A Trivial Fix, Thirteen Months Late
The technical remedy was minor. The researcher described it as a trivial authentication gate, the kind of fix a competent team closes quickly. Reaching it took far longer. By the report’s timeline, the issue was flagged to India’s CERT-In on June 8, 2026, IDRBT deployed a fix on June 25, and CERT-In confirmed it closed on June 26, roughly 18 days after disclosure and around 13 months after the endpoints first went live unprotected. As of the public reporting, neither IDRBT nor the RBI had issued a statement.
The Badge Is Only as Good as the Registry
None of this means .bank.in has failed at its purpose. The suffix still does what it was built to do against ordinary lookalike phishing, and the exposure was closed before any confirmed misuse. The lesson is narrower and more familiar. A trust namespace is only as trustworthy as the registry behind it, and unauthenticated APIs remain one of the most common and most preventable ways for that trust to leak. Building the badge is the easy part. Securing the system that issues it is the job that never ends.
