India’s central bank-affiliated domain registry for the .bank.in namespace — a system mandated by the Reserve Bank of India to protect banks from phishing and impersonation — exposed the personal and login credentials of 5,576 bank employees through more than 33 unauthenticated API endpoints for at least 13 months.
How 33 Unauthenticated IDRBT Endpoints Exposed an Entire Registry Backend
The IDRBT Domain Registration Portal, operated by the Institute for Development and Research in Banking Technology at registrar.idrbt.ac.in, manages the assignment of .bank.in domain names. IDRBT is affiliated with the Reserve Bank of India and serves as the exclusive registrar for the .bank.in namespace — the high-trust domain space that Indian banks were mandated to use specifically to give customers a reliable way to identify legitimate banking sites.
The portal’s entire backend was accessible through more than 33 unauthenticated REST API endpoints. Any internet user with basic tools such as curl could query those endpoints and retrieve the complete database of registry users. The data available through the open endpoints included bcrypt password hashes, mobile phone numbers, email addresses, login IP addresses, and device fingerprints for all 5,576 bank employees authorized to manage India’s banking domain infrastructure.
What the Open IDRBT API Endpoints Returned to Any HTTP Client
The breadth of data returned by the unauthenticated endpoints made the exposure particularly severe. Bcrypt password hashes, while hashed rather than plaintext, can be subjected to offline cracking attempts using modern hardware. Mobile phone numbers and email addresses provide direct contact vectors for social engineering or phishing. Login IP addresses and device fingerprints allow an attacker to profile when and how registry administrators access the portal — information useful for planning access attempts or impersonation attacks timed to mimic normal administrator behavior.
The exposure lasted at least 13 months before a security researcher discovered the open endpoints and reported them to IDRBT in early June 2026. IDRBT applied fixes after receiving the report. At the time of the first public reporting of the exposure, neither IDRBT, the Reserve Bank of India, nor the Indian government had issued any public statement acknowledging the incident.
How the Anti-Phishing .bank.in Initiative Became a Phishing Enabler
The .bank.in domain was a deliberate policy choice by the Reserve Bank of India. The logic behind it was straightforward: if Indian banks operate exclusively under a restricted, regulated namespace, customers can trust that a .bank.in URL is genuinely affiliated with a bank rather than a phishing site impersonating one. The registry’s security was therefore not incidental to the initiative’s purpose — it was central to it.
The 5,576 employees exposed in the IDRBT breach are precisely the administrators who manage India’s banking domain infrastructure. Credentials and contact data for those employees — the people who control which domains are assigned to which banks — could enable an attacker to impersonate a bank administrator, intercept domain management communications, or redirect legitimate bank domains to attacker-controlled servers. The anti-phishing initiative’s own registry leaked the data that would be most useful to an attacker attempting exactly the impersonation the initiative was designed to prevent.
IKCON Technologies, Single-Source Contracting, and the Missing Security Audit
The IDRBT portal was built by IKCON Technologies, awarded the contract without a competitive tender process — a procurement approach that the investigation found was in violation of IDRBT’s own procurement handbook. The single-source award meant that no competitive evaluation required the vendor to demonstrate security practices, and the resulting portal was not subjected to a competent security audit before it was placed into production handling sensitive data for all 5,576 bank employees.
A security audit of the portal would have identified the 33 unauthenticated endpoints — a flaw described in reporting as something no competent audit would have missed. The combination of procurement irregularity, absent security testing, and a 13-month exposure window before external discovery underlines that the failure was not a sophisticated evasion of security controls, but a basic security review that did not occur before the system was made live.
