Tata Nexarc has fixed a critical authentication flaw that exposed login one-time passwords (OTPs) in client-visible API responses.
The issue could have allowed an unauthenticated attacker who knows a registered mobile number to obtain the OTP required for passwordless login and seize the account.
Eaton reported the vulnerability to the Indian Computer Emergency Response Team (CERT-In) on July 30; CERT-In confirmed a fix. Public disclosure followed on August 24.
Tata B2B Platform Flaw
Tata Nexarc uses an OTP workflow to authenticate users using an email address or a mobile number. Eaton found that the request initiating this workflow returned a field named otpGeneratedForMobile in the response.
Although the payload was AES-encrypted, the platform’s client-side JavaScript included the logic needed to decrypt and process it.
That design meant encryption did not protect the secret from the person operating the browser: the plaintext OTP was available to the client. The field was reportedly not required by the front end, making its inclusion unnecessary.
An OTP is intended to prove possession of a phone or email inbox. Returning it to the client that requests authentication collapses that security boundary.
An attacker could use the exposed value to complete authentication without accessing the delivery channel or guessing the code.
Eaton reported accessing accounts with administrative capabilities, including corporate profile changes, employee management, order and shipment history, licenses, marketplace activity, subscriptions, proposals, and notifications.
One number guessed during testing mapped to a Tata Business Hub account, and another was linked to Tata Steel. These claims describe potential impact, not independently verified evidence that data was altered or extracted.
The disclosure stated that the researcher did not identify a method for mass exfiltration of phone number records. Still, permissions available through compromised business accounts could have exposed operational and commercial information and enabled unauthorized changes.
CERT-In acknowledged the report on July 30 and confirmed the flaw was fixed on July 31. The remedial change removed otpGeneratedForMobile from the API response.
The incident illustrates why client-side encryption is not a substitute for server-side access control. A client must never receive a credential or verification secret it is not meant to reveal.
OTP generation and validation should remain on the server, and APIs should return only the minimum state needed for the next step, such as a transaction reference and generic delivery status.
Organizations operating passwordless authentication should also test API responses in a browser context, rather than merely inspecting encrypted network traffic.
Reviews should verify that secrets cannot be recovered through front-end code, logs, error messages, analytics payloads, or debugging tools.
Short OTP lifetimes, single-use enforcement, rate limits, and monitoring remain layers, but none compensate for sending the code directly to an unauthenticated client.
Give your security team the visibility and context to investigate suspicious activity faster and contain threats before business impact grows. Strengthen Your Investigations with ANY.RUN
 in client-visible API responses.){kind=link}