Tata Nexarc Critical OTP Flaw Exposed Login Codes, Risking Business Account Takeovers

Tata Nexarc, the business-to-business digital platform operated by Tata, has fixed a critical authentication vulnerability that exposed login one-time passwords (OTPs) through client-visible API responses.

The flaw could have allowed an unauthenticated attacker who knew a registered mobile number to retrieve the OTP required for passwordless authentication and potentially take control of the associated account.

The vulnerability was discovered and reported by security researcher Eaton to the Indian Computer Emergency Response Team (CERT-In) on July 30, 2026.

Tata Nexarc Critical OTP Flaw Exposed

According to the disclosure, CERT-In acknowledged the report and confirmed that Tata Nexarc had implemented a fix by July 31.

Details of the issue were publicly disclosed on August 24, highlighting the risks created when authentication secrets are unnecessarily delivered to client-side applications.

Tata Nexarc uses an OTP-based authentication workflow that allows users to initiate login using a registered email address or mobile number.

During testing, Eaton discovered that the API request responsible for initiating the OTP process returned a parameter named otpGeneratedForMobile. The field contained the generated OTP in a form that could ultimately be recovered by the client.

Although the API response was encrypted using AES, the protection did not provide meaningful security against a user controlling the browser.

Eaton reported that Tata Nexarc’s client-side JavaScript contained the functionality and information necessary to decrypt and process the response.

Consequently, an attacker interacting with the legitimate application could potentially recover the OTP without having access to the victim’s phone or email account.

The issue was particularly significant because the OTP was intended to establish possession of the registered authentication channel.

By returning the authentication secret to the same client requesting access, the application effectively weakened the security boundary that the OTP mechanism was designed to provide.

An attacker who knew a valid registered mobile number could potentially obtain the corresponding OTP and complete the authentication process.

Eaton reported successfully reaching accounts with administrative capabilities during testing. These permissions reportedly included access to corporate profile management, employee administration, order and shipment histories, licenses, marketplace activity, subscriptions, proposals, and notifications.

The disclosure referenced accounts associated with Tata Business Hub and Tata Steel during testing. However, these observations should be treated as reported potential impact rather than independent evidence that customer data was modified or extensively exfiltrated.

The researcher also stated that no method was identified for mass extraction of registered phone numbers. Nevertheless, the ability to authenticate into business accounts could have created significant risks because compromised accounts may contain sensitive operational, commercial, employee, and transaction-related information.

Unauthorized access could also potentially allow attackers to modify business information or manipulate account-level settings.

Tata Nexarc addressed the vulnerability by removing otpGeneratedForMobile from the API response. This remediation reflects an important security principle:

Authentication credentials and verification secrets should remain exclusively on the server side whenever possible. The client should receive only the minimum information required to continue the authentication transaction, such as a temporary transaction identifier and a generic indication that an OTP was sent.

The incident also demonstrates why encryption of API responses should not be considered a replacement for proper server-side security controls.

If a browser is capable of decrypting sensitive information, an attacker controlling that browser may also be capable of accessing the plaintext.

Security testing should therefore examine application behavior from the perspective of an authenticated or unauthenticated client rather than assuming encrypted network traffic is automatically secure.

Organizations implementing passwordless authentication should ensure that OTP generation and validation remain server-side, while API responses contain no unnecessary secrets.

Security reviews should additionally inspect front-end JavaScript, browser storage, logs, debugging interfaces, analytics payloads, and error responses for accidental exposure of authentication data.

Short OTP expiration periods, single-use enforcement, rate limiting, abuse detection, and authentication monitoring remain valuable defensive layers.

However, these controls cannot fully compensate for an architecture that directly exposes a valid authentication secret to an unauthorized client.

The Tata Nexarc incident reinforces a fundamental lesson for modern API security: sensitive authentication material should never be returned to a client unless the client is explicitly trusted to receive it.