Connected Vehicle Cybersecurity: Tata Motors iRA App Vulnerabilities – Understanding the Four Cybersecurity Risks in Connected Cars
What did CERT-In find in Tata Motors' connected-car apps?
On 4 November 2026, CERT-In, India's national cybersecurity agency, rated four vulnerabilities in Tata Motors' iRA 2.0 and iRA.ev apps as High severity in advisory CIVN-2026-0537. iRA 2.0 serves petrol and diesel customers. iRA.ev serves electric vehicle customers. Both apps let owners send remote vehicle commands, check vehicle status and health, and view trip information.
This matters because a modern car is no longer just wiring and ECUs. It is also a phone app, a cloud backend and a telematics link. A weakness in any one of them can expose the others.
Tata Motors Passenger Vehicles says it released fixes before the advisory went public: updates in August 2026 (iRA 2.0) and September 2026 (iRA.ev). Its own assessment found no evidence of unauthorised access to customer credentials, personal information or vehicle-related data. The CERT-In advisory does not report any exploitation. This is therefore a case study of weaknesses that were found and fixed, not a confirmed vehicle hack or data breach.
Throughout this article, we separate four kinds of statements: CERT-In findings, Tata Motors statements, potential scenarios (what an attacker could theoretically do) and recommended practices.
How does a connected-car app work?
The flow below is a general connected-vehicle pattern, not a description of Tata Motors' internal design. Take a simple example: an owner checks where the car is parked.
The owner opens the iRA app and taps "Find my car".
The app sends a request over the internet to the carmaker's backend server.
The backend checks who is asking and what that person is allowed to do.
The backend contacts the vehicle through its telematics control unit (TCU), the module that connects the car to the mobile network.
The vehicle replies with its data, or carries out an authorised command, and the answer travels back to the phone the same way.
The two highlighted components, the phone app and the backend services it uses, are where CERT-In's four findings apply. The telematics unit and vehicle ECUs are shown for context only.
The app, the backend and the vehicle link are connected but separate components. Each has its own weak points. The CERT-In advisory concerns the mobile apps and the backend services they talk to. It says nothing about the TCU or the in-vehicle network.
The four vulnerabilities, explained simply
Each flaw has a CVE identifier, which is a public reference number for a known security weakness. Below, each section uses CERT-In's own title and wording as the baseline.
Hardcoded credentials (CVE-2026-121144)
CERT-In finding: the iRA 2.0 and iRA.ev apps contained hardcoded service account credentials, API keys and authorisation tokens inside the application package. An unauthenticated remote attacker could download the package and extract them.
What happened? Secret login details were stored inside the app itself.
What do the terms mean? Hardcoded means typed directly into the app's code. A service account is a login used by software, not by a person. An API key is a password-like string that identifies an app to a server. An authorisation token is a digital pass that proves permission. The application package (an APK on Android) is the file people download to install the app.
How should it work? Secrets stay on protected servers. The app carries nothing that would be dangerous if copied, and users prove who they are by logging in.
What went wrong? Secrets shipped inside every copy of the app, and every copy is public.
How could an attacker exploit it? (Potential scenario)
Download the app from a public app store.
Unpack the package with freely available tools. An APK is an archive that can be opened and inspected.
Search the unpacked code and files for keys, tokens and credentials.
Try them against the backend services they belong to.
What could happen? CERT-In says an attacker could gain unauthorised access to backend services and potentially reach sensitive information or perform unauthorised operations.
Real-world example: a company hands customers access cards but accidentally leaves a master key in the packaging. Anyone who opens the packaging can find it.
How to prevent it: keep secrets on the server, issue short-lived tokens with narrow permissions after login, scan every build for embedded secrets before release, use a secrets manager, and rotate any credential that has ever shipped inside an app.
2. Improper WebView URL validation (CVE-2026-121145)
CERT-In finding: listed as an "Insecure Configuration" vulnerability. The apps had insufficient validation of URLs and origins loaded within the WebView component. A remote attacker could send malicious web content to the WebView, interact with app functions, obtain live bearer authentication tokens and potentially impersonate the user.
What happened? The app's built-in web window did not properly check which web addresses it was loading.
What do the terms mean? A WebView is a component that shows web pages inside a mobile app, so developers can reuse web content instead of rebuilding screens. URL validation means checking that a full web address is one the app trusts. Origin validation means checking which site (domain, protocol and port) the content comes from. An untrusted website is any site the app owner does not control. A bearer token is a digital pass that works for whoever holds it.
How should it work? The WebView loads only an approved list of the company's own pages. Anything else opens in the normal browser or is blocked.
What went wrong? The checks on URLs and origins were not strict enough, so content the app should not trust could be loaded.
How could an attacker exploit it? (Potential scenario)
Prepare malicious web content. CERT-In does not describe how it reaches the app. In general, the attacker needs some way to get the app to load content they control.
The content loads inside the WebView, where the app treats it as part of itself.
The content interacts with app functionality available to the WebView.
It captures a live bearer token.
The attacker presents that token to the backend and acts as the owner.
What could happen? Per CERT-In: unauthorised interaction with app functionality, token theft, user impersonation, and access to vehicle information and services.
Real-world example: a banking app should open only the bank's official website, but it also lets an untrusted site load inside its secure area.
How to prevent it: allow only exact, approved HTTPS origins (an allowlist), block everything else, keep tokens and sensitive app functions out of reach of web content, turn off WebView features the app does not need, and test navigation rules before release.
3. Authentication tokens in application logs (CVE-2026-121146)
CERT-In finding: listed as an "Information Disclosure" vulnerability. Authentication tokens were recorded in application logs used for development and debugging. A local attacker with access to those logs could retrieve the exposed session tokens and misuse them. This is a separate weakness from the WebView issue: here the tokens leak through logs, not through web content.
What happened? The app wrote live login tokens into its own diary of activity.
What do the terms mean? An authentication token is proof that you already logged in, so you are not asked for your password on every request. A bearer token works for whoever holds it, like cash. A session token identifies one login session. Application logs are the running notes an app writes so developers can find and fix bugs.
How should it work? Logs record events such as errors, never secrets. Anything sensitive is masked or left out.
What went wrong? Tokens were being written to logs meant for development and debugging, where more people and tools can read them than should ever see a token.
How could an attacker exploit it? (Potential scenario)
Gain local access to the logs. CERT-In specifies local access; who can read logs depends on the device and setup.
Find a token among the log entries.
Send that token to the backend. While it remains valid, the backend sees the owner.
What could happen? Per CERT-In: impersonating the user and gaining unauthorised access to vehicle information and services.
Real-world example: a bank employee writes a customer's temporary access code in an unsecured office register. Whoever picks up the register can use the code.
How to prevent it: never log tokens or other secrets, mask sensitive fields, switch off verbose debug logging in release builds, keep token lifetimes short, and revoke tokens at logout or when misuse is suspected.
4. Improper SSL certificate pinning (CVE-2026-121147)
CERT-In finding: listed as a "Security Misconfiguration" vulnerability. SSL certificate pinning was improperly implemented in the network security configuration, making the pinning controls ineffective. An attacker positioned to intercept network traffic could intercept or modify communications between the app and its backend.
What happened? An extra safeguard on the app's connection to its server was set up in a way that did not work.
What do the terms mean? HTTPS is web traffic that is encrypted. SSL/TLS is the encryption technology behind it. A digital certificate is a server's ID card, issued by a trusted authority. Certificate pinning means the app is told in advance exactly which certificate or key to trust, so a different one is rejected. A man-in-the-middle (MitM) attack is when someone sits between the app and the server, reading or changing the traffic.
How should it work? The app checks the server's certificate against its trusted authorities and against the pinned value. If either check fails, the connection is refused.
What went wrong? The pinning setup did not enforce what it was meant to, so the second check offered little protection.
How could an attacker exploit it? (Potential scenario)
Get into the network path between the phone and the server, which CERT-In calls being "positioned to intercept network traffic".
Present a certificate that proper pinning would have rejected.
Because pinning is ineffective, the app may accept it.
Read or modify the traffic passing between the app and the backend.
What could happen? Per CERT-In: interception or modification of communications between the app and its backend services.
Real-world example: a company sends confidential documents by courier. The courier is supposed to verify the recipient's identity, but that verification step was configured incorrectly.
How to prevent it: implement pinning correctly, pin public keys with backup pins and a rotation plan, refuse the connection when a check fails, and test it against an intercepting proxy before every release.
Important: ineffective pinning does not mean HTTPS encryption was broken. Pinning is an additional layer on top of it, and CERT-In does not say the underlying encryption failed.
What could the impact be on connected vehicles?
CERT-In's risk assessment names unauthorised access to sensitive information, user impersonation and unauthorised modification of application data, all with the privileges of the impersonated user. In plain terms, the potential impacts are:
Potential impact | Linked weakness | Status |
Exposure of credentials and backend access | Hardcoded credentials | Potential, per CERT-In |
Customer account impersonation | WebView, token logging | Potential, per CERT-In |
Unauthorised use of connected services such as vehicle status, health and trip information | All four | Potential, per CERT-In |
Exposure of vehicle and trip information, which could include location-type data | Token theft, interception | Potential scenario, not stated by CERT-In |
Misuse of remote commands the real owner could send | Token theft | Potential scenario, limited to the owner's own permissions |
Interception or alteration of app-to-backend traffic | Ineffective certificate pinning | Potential, per CERT-In |
What is not established. The advisory does not report active exploitation, name affected vehicle models or give customer numbers. It does not say the braking ECU, engine ECU or any physical vehicle control system was compromised. The risks it describes sit at the app and backend layer.
How did Tata Motors respond?
Tata Motors Passenger Vehicles said the issues were fixed through software updates and enhanced security measures. The fixes shipped before CERT-In published the advisory on 4 November 2026.
Topic | Detail | Source |
Affected versions | iRA 2.0: 26.7.3 and below. iRA.ev: 26.7.2 and below | |
Fixed versions | iRA 2.0: 26.8.2. iRA.ev: 26.9.1 | |
Update rollout | iRA 2.0 in August 2026, iRA.ev in September 2026 | Tata Motors statement |
How updates reach users | Prompted automatically when the app opens, installed over the air in a few minutes | Tata Motors statement |
Active users | Rollout complete for all active users | Tata Motors statement |
Users yet to update | Tata Motors is reaching out to them proactively | Tata Motors statement |
Impact assessment | No evidence of unauthorised access to, or compromise of, customer credentials, personal information or vehicle-related data | Tata Motors' own assessment |
The impact assessment is the company's own and has not been independently verified. Only users on the listed older versions were within the advisory's scope, so it would be wrong to say every customer was affected. Tata Motors' statement was reported by Business Standard, PTI and Business Today.
What can automotive OEMs learn from this?
These are recommended practices, drawn from the weakness types CERT-In described.
They are not a claim about how Tata Motors builds software.
Secure app development: follow a recognised mobile standard such as OWASP MASVS from the first sprint, not at the end.
API security: assume anyone can call your backend, and enforce identity and permissions on every request.
Credential management: no secrets in app packages. Use a secrets manager and short-lived tokens.
WebView validation: load only allowlisted origins and expose nothing sensitive to web content.
Token management: short expiry, revocation at logout, and detection of reuse.
Secure logging: never log tokens, and strip debug logging from release builds.
Certificate pinning: implement it correctly, with backup pins, and test that it actually blocks a fake certificate.
Mobile and API penetration testing: test the released build the way an attacker would, before and after launch.
TARA: include the app, the backend and the telematics link as assets when assessing threats.
Vulnerability management: a clear route to receive reports, triage, fix and verify.
CSMS: run cybersecurity as a lifecycle process, not a one-time check.
Secure software updates: be able to ship a fix quickly and verify that users receive it.
How can Ettiksoft help prevent similar risks?
Incidents like this highlight why automotive cybersecurity needs to be integrated into the entire vehicle development and connected-service lifecycle, rather than addressed only after vulnerabilities are discovered.
Ettiksoft Technologies supports automotive OEMs with the following capabilities. We do not claim any role in the Tata Motors case; the point is how earlier controls could help catch weaknesses of this kind before release.
AutoPentrix (Automotive Penetration Testing): security testing that finds weaknesses before attackers do. Testing areas relevant to a connected vehicle are ECUs, CAN and Automotive Ethernet, infotainment and telematics, mobile apps, and APIs and backend services.
TARA (Threat Analysis and Risk Assessment): identifies assets, threats, attack paths and impacts at design stage, so the app, backend and telematics link are assessed before launch.
CSMS (Cybersecurity Management System): keeps cybersecurity running as a lifecycle process: risk management, monitoring, incident response and fixes.
AIS-189 / UN R155: frameworks for managing vehicle cybersecurity systematically.
AIS-190 / UN R156 / SUMS: frameworks for managing software updates, including integrity and the rollout of fixes.
Sec-En-Pro-HSM: a hardware security module that protects cryptographic keys and supports secure ECU operations.
CyberBoot: secure boot that checks firmware integrity at ECU level.
How AutoPentrix, TARA and CSMS fit together: TARA decides what matters and what to test. AutoPentrix checks whether the real system holds up. CSMS makes sure each finding is tracked through fix, verification and monitoring.
Mapping the four weaknesses to capabilities
Direct means the capability helps find or assess that class of weakness. Supporting means it strengthens the surrounding process or other layers.
Weakness | Required protection | Ettiksoft capability | How it helps | Type |
Hardcoded credentials Secrets kept off the app; build scanning | AutoPentrix (mobile and API testing Tool) | Can reveal secrets extractable from a released app | Direct, if confirmed | |
TARA, CSMS | Flag secret exposure as a threat; keep secure-development checks in the process | Supporting | ||
WebView URL validation Origin allowlists; WebView hardening | AutoPentrix (mobile testing) | Can test whether untrusted content loads | Direct, if confirmed | |
TARA | Treats web content in the app as a threat path | Supporting | ||
Tokens in logs Secure logging; token expiry and revocation | AutoPentrix (mobile testing to be confirmed) | Can check what an app writes to logs | Direct, if confirmed | |
CSMS | Keeps logging rules and review inside the lifecycle | Supporting | ||
Ineffective certificate pinning Correct pinning, verified by test | AutoPentrix (network testing to be confirmed) | Can test whether interception succeeds | Direct, if confirmed | |
TARA | Includes man-in-the-middle in threat analysis | Supporting | ||
All four, at system level | Fast, verified fixes | SUMS / AIS-190 | Manages how fixes reach users | Supporting |
Sec-En-Pro-HSM and CyberBoot protect keys and software integrity in the vehicle's ECUs. They are supporting layers for the wider system. They do not fix WebView, logging or certificate-pinning flaws in a mobile app.
Conclusion: the attack surface goes beyond the ECU
Automotive cybersecurity must extend beyond the vehicle's electronic control units. Mobile applications, APIs, backend infrastructure, telematics and software updates are all part of the connected-vehicle attack surface.
The iRA advisory shows four ordinary, well-understood weakness types: secrets in an app, loose web content checks, tokens in logs and a pinning setup that did not work. Each can be found by testing and assessed during design. Each is easier to fix when caught early.
Ettiksoft Technologies works as an automotive cybersecurity partner, helping OEMs identify, assess, test and manage cybersecurity risks across the vehicle and its connected services. If your engineering or technology team is reviewing its connected-vehicle security, we would be glad to start a conversation.
Explore Ettiksoft's Automotive Cybersecurity capabilities at ettiksoft.com or contact our team to discuss your programme.
Frequently asked questions:
What did CERT-In find in the Tata iRA apps? CERT-In advisory CIVN-2026-0537 rates four vulnerabilities in iRA 2.0 and iRA.ev as High severity: hardcoded credentials, insecure WebView configuration, authentication tokens in logs and ineffective SSL certificate pinning.
What are iRA 2.0 and iRA.ev? They are Tata Motors connected-vehicle apps for ICE and EV customers. They provide remote vehicle commands, vehicle status and health monitoring, and trip information.
Was there a confirmed Tata Motors data breach or vehicle hack? No. The advisory reports no exploitation, and Tata Motors says its assessment found no evidence of unauthorised access to customer credentials, personal information or vehicle-related data.
Which app versions were affected, and what is the fix? iRA 2.0 version 26.7.3 and below, and iRA.ev version 26.7.2 and below. CERT-In advises upgrading to 26.8.2 and 26.9.1 respectively.
Does ineffective certificate pinning mean HTTPS was broken? No. Pinning is an extra layer on top of HTTPS. CERT-In says the pinning controls were ineffective, not that the underlying encryption failed.
Does this mean a car's brakes or engine could be controlled through the app? The advisory does not say that. Its risks are unauthorised access to information and services with the impersonated user's privileges.
How can OEMs secure connected-car apps? Keep secrets off the app, validate WebView origins, never log tokens, implement and test certificate pinning, run mobile and API penetration tests, and manage risk through TARA and a CSMS.
References
CERT-In, Vulnerability Note CIVN-2026-0537: Multiple Vulnerabilities in Tata Motors iRA and iRA.ev Application, issued 4 November 2026. Primary source for all technical findings, CVE identifiers and versions.
Business Standard, Tata Motors' iRA apps vulnerable to data theft, user impersonation: CERT-In, 5 November 2026. Tata Motors statement.
PTI via ETV Bharat, CERT-In-flagged app vulnerabilities addressed through updates: Tata Motors PV, 5 November 2026. Tata Motors statement.
Business Today, Tata Motors says customer data is safe after CERT-In flags security flaws in connected-car apps, 5 November 2026. Tata Motors statement.
Cyber Security News, Tata Motors iRA App Flaws Could Let Hackers Impersonate Car Owners and Access Vehicle Services, 5 November 2026. Secondary technical summary.
The Hindu BusinessLine, CERT-In flags vulnerability in Tata Motors mobile apps.
The attack steps in this article are potential scenarios based on CERT-In's descriptions. They are not reports of actual attacks.
Comments