# Tata Nexarc's OTP Leak: How "Encrypted" Didn't Mean Safe 🚨
One phone number. Zero hacking skills. Full admin access.
A critical authentication flaw in Tata Nexarc, a B2B procurement platform under the Tata Group used by thousands of SMBs across India, let attackers take over accounts using nothing but a registered mobile number.
What went wrong
The login endpoint CheckForUsersRegisteredWithEmailOrMobileNoAndSendOTP.do returned the OTP directly inside its own response, in a field called otpGeneratedForMobile.
Technically "encrypted" (AES) — but the decryption logic ran entirely in client-side JavaScript.
That means:
- No phishing
- No SIM swap
- No brute force
Just a browser, a target's phone number, and a breakpoint set at the decryption function. The OTP appeared in plaintext.
The impact
Testing confirmed real admin-level access to accounts linked to Tata Business Hub and Tata Steel — exposing employee data, order history, licensing info, and marketplace/proposal management functions.
The fix
Reported to CERT-In on July 30, 2026. Confirmed patched the next day, July 31, 2026 — the vulnerable field was removed from the API response.
The takeaway for devs
If the client can decrypt it, so can an attacker.
Best practices for OTP flows:
- Never return the OTP to the client, in any form
- Validate OTPs server-side only
- Bind OTP sessions to the requesting device/session token
- Enforce rate limits + short expiry windows
- Monitor for repeated OTP-generation requests against different numbers (enumeration signal)
Full technical breakdown, tools used, and disclosure timeline: Xpert4Cyber's writeup
What's the worst "encrypted but not really" auth flaw you've seen in the wild? 👇
Top comments (0)