Tata Nexarc Account Takeover Bug: All It Took Was a Phone Number

Tata Nexarc OTP Leak: How a Single Phone Number Could Hijack Any B2B Account

Picture this: you're a SOC analyst reviewing a bug bounty disclosure at 11 PM, and the report says the attacker didn't phish anyone, didn't intercept an SMS, and didn't even brute-force a four-digit code. All they needed was a phone number and a browser's developer console. That's not a hypothetical — that's exactly what happened to Tata Nexarc, a B2B procurement platform used by small and medium businesses across India to source steel and building materials.

A researcher found that the platform's own login API was quietly handing out the one-time password meant to protect the account. No interception. No social engineering. Just a decrypted API response sitting in plain sight in the browser's memory.

Table of Contents

• What Actually Happened
• Technical Breakdown of the Flaw
• Real-World Impact: Tata Business Hub and Tata Steel
• Key Indicators and API Behavior
• Tools and Techniques Used in the Disclosure
• Detection and Prevention for Your Own Applications
• Expert Tips for SOC Teams and Developers
• Related Reading
• FAQ
• Conclusion

What Actually Happened

Tata Nexarc is a digital platform under the Tata Group that helps SMBs in India find verified suppliers, manage procurement, and run day-to-day business operations. Like most modern web apps, it uses OTP-based login: enter your registered mobile number, receive a code by SMS, and enter it to authenticate.

That flow works fine — as long as the server keeps the OTP to itself. In this case, it didn't. A security researcher discovered that the login API not only sent the OTP to the user's phone, it also returned that same OTP inside the API response sent back to the browser. Anyone who could read that response could log in as the victim, without ever touching the victim's phone.

Technical Breakdown of the Flaw

The login flow calls an endpoint named CheckForUsersRegisteredWithEmailOrMobileNoAndSendOTP.do. Functionally, this endpoint checks whether a mobile number or email is registered and triggers OTP delivery. The problem was in what it sent back.

The response included a field called otpGeneratedForMobile, containing the exact same OTP that had just been texted to the account holder. On paper, the traffic was encrypted, which might have given the development team false confidence. But the encryption and decryption logic was implemented in client-side JavaScript using AES — meaning the browser itself had to hold the decryption key and logic to render the page.

That's the fatal design flaw. If the client can decrypt it, so can anyone controlling that client. The researcher simply set a breakpoint in the browser's JavaScript debugger at the point where the app decrypts the API response, and read the OTP straight out of memory in plaintext.

Endpoint: CheckForUsersRegisteredWithEmailOrMobileNoAndSendOTP.do
Exposed field: otpGeneratedForMobile
Encryption: AES (client-side JS implementation)
Attack method: Browser breakpoint on decryption function

This turns what should be a two-factor authentication mechanism into what's effectively a client-side secret disclosure vulnerability — the "second factor" was never actually secret from the person trying to log in.

Real-World Impact: Tata Business Hub and Tata Steel

This wasn't a theoretical finding. The researcher tested it against real accounts and confirmed the severity firsthand. A guessed mobile number turned out to be linked to Tata Business Hub's primary account, which carried full administrator privileges.

That access reportedly extended to:

• Corporate page and company profile management
• Employee administration
• Order history and shipment details
• Subscription and licensing information
• Marketplace functions and proposal management
• Account notifications

The researcher also gained administrator access to an account tied to Tata Steel using a mobile number associated with that organization. For a B2B platform handling procurement, licensing, and vendor relationships, that level of access in the wrong hands could mean manipulated orders, exposed contracts, or disrupted supply chain operations.

There's one limiting factor worth noting for anyone assessing real-world exploitability: the disclosure didn't include a method for bulk-harvesting phone numbers from the platform. That kept this from being a mass-exploitation scenario. Still, attackers didn't need a database dump — publicly available numbers, or numbers exposed through the platform's own "Manage Employees" pages after compromising one account, were enough to pivot toward higher-value targets.

Key Indicators and API Behavior

If you're a defender trying to spot similar issues in your own environment, these are the tell-tale signs worth flagging during a code or API review:

• Login or OTP-verification endpoints returning any field resembling the generated code (otp, code, token, otpGeneratedFor*) in the response body
• Encryption/decryption logic implemented entirely in client-side JavaScript for authentication-sensitive data
• API responses that are larger or more detailed than what the visible UI actually consumes
• No server-side validation gate between "OTP requested" and "OTP submitted" stages

Tools and Techniques Used in the Disclosure

The researcher's methodology here is a good reminder that finding this class of bug doesn't require exotic tooling — just careful observation of normal application behavior.

• Browser DevTools: Used to set a breakpoint on the JavaScript function responsible for decrypting the API response, exposing the plaintext OTP before it was discarded.
• Manual API traffic review: Reading through the raw request/response cycle of the login flow to understand what data the server was actually sending versus what the UI displayed.
• Burp Suite or an equivalent intercepting proxy is the standard tool SOC analysts and pentesters would use to replicate this kind of analysis, capturing and replaying the OTP-request call against different mobile numbers.

Detection and Prevention for Your Own Applications

Whether you're a developer, an AppSec engineer, or a SOC analyst reviewing vendor risk, this incident maps to a few concrete, actionable controls:

For Developers

• Never return the OTP, or any derivative of it, in an API response — encrypted or not. Validation must happen entirely server-side.
• Don't implement authentication-critical decryption logic in client-side JavaScript. If the browser can decrypt it, so can an attacker.
• Enforce OTP expiry (typically 60–180 seconds) and strict rate limiting per mobile number and per IP address.
• Bind the OTP session to the requesting device/session token so a code generated in one context can't be replayed elsewhere.

For SOC Teams and Blue Teamers

• Monitor authentication logs for repeated OTP-generation requests against different mobile numbers from the same IP or session — a strong indicator of account enumeration.
• Flag unusual login success patterns immediately following multiple failed or repeated OTP triggers.
• Where possible, correlate login events with device fingerprinting to catch account takeover attempts that reuse a valid OTP from an unfamiliar device.

For Third-Party Risk Managers

• Ask vendors directly whether OTPs or session secrets are ever included in API responses, even in encrypted form.
• Request evidence of independent penetration testing for any B2B platform handling procurement, financial, or employee data.

Expert Tips

• Tip 1: When reviewing any authentication API, treat "it's encrypted" as an incomplete answer. Ask where the decryption key and logic actually live — server or client.
• Tip 2: Response payload size is an underrated red flag. If a login response is noticeably larger than what the UI renders, there's likely unused data leaking through.
• Tip 3: This case had a same-day acknowledgment and a next-day fix from CERT-In and Tata — a strong example of what a healthy responsible disclosure timeline should look like. Compare that against your own organization's mean-time-to-remediate for critical auth flaws.

Disclosure Timeline

Date	Event
July 30, 2026	Vulnerability reported to CERT-In; acknowledged same day
July 31, 2026	CERT-In confirms fix; otpGeneratedForMobile field removed from API response
August 24, 2026	Researcher's public disclosure published
August 25, 2026	Broader security media coverage begins

Related Cybersecurity Topics You Should Explore

• Zscaler Client Connector Flaw Lets Hackers Run Code Remotely
  
• 91 Spring CVEs Impact 209,000+ Components — Critical RCE Flaw Found
  
• SynkLoader Malware Fakes Windows Lock Screen to Steal Passwords
  
• SysScan Scam: Fake Microsoft Alert Tricks Users Into Deleting AV
  
• 768 Leaked AWS Keys Still Have Full Admin Access in 2026
  
• Enable Maximum Windows Logging for SOC & Ransomware Detection
  
• OpenBin.ai & OpenAPK.ai Review: Free AI Reverse Engineering Tool
  
• Grok Zero-Click Hack Steals Your Chats — No Click Needed
  
• head Command in Linux: Fast Log Triage for SOC Analysts
  
• Elementor Pro Bug Lets Hackers Upload PHP — No Login Needed
  
• tac Command Tutorial: Reverse Logs Fast for Faster Threat Detection
  
• ToxicPanda 2.0: The Android Trojan Now Hacking 349 Banks

FAQ

Q1: What is Tata Nexarc?
It's a B2B digital platform under the Tata Group that connects small and medium businesses in India with verified suppliers, primarily in steel and building materials procurement.

Q2: How did the OTP leak actually work?
The login API returned the generated OTP inside its own response, in a field decrypted by client-side JavaScript, allowing anyone who could read that response to obtain the valid login code.

Q3: Did attackers need to intercept SMS messages?
No. That's what made this flaw dangerous — the OTP was available directly from the API response, bypassing the need for SIM swapping, SMS interception, or phishing entirely.

Q4: Could this be exploited at scale?
Not easily. The disclosure didn't include a way to bulk-harvest phone numbers, which limited mass exploitation, though targeted attacks using known or discoverable numbers were still very much possible.

Q5: Has the issue been fixed?
Yes. CERT-In confirmed the fix on July 31, 2026, a single day after the report, with the vulnerable field removed from the API response.

Q6: What's the broader lesson for developers?
Sensitive authentication data like OTPs should never leave the server in any form accessible to the client, regardless of encryption. Validation logic belongs entirely on the backend.

Conclusion

This wasn't a zero-day, a nation-state exploit, or some obscure memory corruption bug. It was a basic API design mistake — sending back data the client never should have seen — and it was enough to hand over full administrator control of enterprise accounts tied to major Tata Group businesses. That's the uncomfortable truth about most account takeover vulnerabilities: they rarely need sophistication, just a developer assumption that went unchecked.

If you're building or auditing authentication flows, take this as a prompt to go back and check exactly what your own OTP or session-verification APIs are returning. If you found this breakdown useful, share it with your team, and drop a comment if you've seen similar client-side decryption mistakes in the wild.