Tata Nexarc, a B2B procurement platform serving small and medium businesses in India, recently suffered a severe flaw in its OTP-based authentication system that allowed attackers to hijack user accounts with nothing more than a registered mobile number. This platform, which facilitates purchases of steel and building materials, unintentionally exposed the one-time password (OTP) needed for login through its API response — eliminating the need for phishing, intercepting SMS, or brute-forcing codes.
What Went Wrong
The flaw resided in an API endpoint named CheckForUsersRegisteredWithEmailOrMobileNoAndSendOTP.do. When this endpoint was triggered, it not only initiated OTP delivery by SMS but also included the plaintext OTP in the API’s response in a field called otpGeneratedForMobile. While the communication between client and server was encrypted overall, decryption and validation occurred in browser-based JavaScript using client-side AES logic. By inserting a breakpoint in that JavaScript, a malicious actor could view the OTP in clear text.
Essentially, the designed protection offered by mobile OTP verification was undermined: if an attacker submitted someone’s mobile number, they could receive the same OTP that, in theory, only the legitimate user should get. From there, signing in as that user was trivial. Internal logic has no benefit for ever returning the OTP to the client, yet it was present in responses, creating exposure without operational necessity.
Potential Impact & Scope
Testing showed that this vulnerability could become very dangerous depending on the account’s permissions. For example, one attacker obtained access to a primary “Tata Business Hub” account with administrator privileges, allowing control over employee listings, corporate pages, order histories, subscription details, marketplace features, and more. In another instance, the researcher accessed an administrator seat for an account tied to Tata Steel itself. Importantly, there was no evidence that attackers could perform mass extraction of phone numbers directly — limiting scale, though individual targets are still at high risk. Attackers might discover valid numbers via public sources or by compromising an account that shows staff numbers in visible directories.
Response & Fix
The vulnerability was formally disclosed to India’s Computer Emergency Response Team (CERT-In) on July 30, 2026. The organization acknowledged the report the same day and confirmed that Tata Nexarc removed the problematic otpGeneratedForMobile field from all API responses by July 31, 2026. The researcher publicly revealed the issue on August 24, 2026.
The case underscores key security best practices around OTP systems: the verification codes should never reach client-side JavaScript, should be validated only server-side, should have strict expiry and rate limits, and systems must monitor suspicious login activity, especially when dealing with accounts that hold elevated privileges.
Broader Significance
This incident highlights how even well-known platforms can make simple but devastating mistakes in authentication flows. OTPs are widely deployed as a second factor or proof of identity — but when implementation is flawed, they offer a false sense of security. Systems that return OTPs or other secrets to the client side multiply risks, particularly when combined with enmeshed JS-based decryption and logic.
For businesses and users alike, this attack vector should nudge everyone—platform developers, security auditors, and regulators—to re-check whether their authentication APIs leak sensitive tokens or expose them through front-end logic. The danger isn’t exotic — it’s basic but powerful. What to watch: more scrutiny of SaaS and B2B tools where administrator access can unlock large-scale damage, and demand for audits that cover both server- and client-side components in OTP flows. The lesson here is that secure authentication isn’t just about adding barriers — it’s about ensuring nothing critical is exposed in the open.
