The app shipped with the keys: what a leaked key can reach

CERT-In note CIVN-2026-0537 reports hardcoded credentials, API keys and tokens in the Tata Motors iRA and iRA.ev application packages. Rushlane reports, citing Tata Motors, that updates were rolled out. For the details, check those sources yourself.

What follows is general engineering commentary on this class of flaw, not a statement about how these flaws came about. The weakness, CWE-798, is a decision every embedded team makes on the way to manufacturing, whether they notice it or not.

What the flaw is

A hard-coded credential is a password, API key, token or symmetric key compiled into the image you ship. The note describes the simplest form of the attack: download the package and extract what is inside.

That is only the first step. The key lets someone use the services the app talks to, without the app. This is the real problem. The note's stated result is unauthorized access to associated backend services.

In firmware it usually looks like an MQTT password, a cloud API key or a symmetric update key in a const array or a build-time define.

Why it happens, and why it matters

How easy the key is to reach depends on what you ship. An Android app package is a ZIP archive, so anyone can download and open it. Firmware is harder, and most people will never read it. But harder is not safe. Obfuscation changes how long a key takes to find, not whether it can be found. And if every copy holds the same key, finding it once is enough.

What the key opens decides the damage. In firmware, a shared broker password lets someone connect as any unit. A cloud key with write access could let them change your update files. A key limited to one unit's data does far less harm.

It is often the path of least resistance on the line: one binary, one fixture, no per-unit step, no extra seconds of cycle time. So every board leaves the factory with the same secret. There are two ways out of the device:

• The update image. If your update package is signed but not encrypted, every string in it can be read by anyone who can download it. Signing proves where an image came from. It hides nothing.
• The flash itself. On an STM32L4, the RDP byte in FLASH_OPTR sets the readout protection level: 0xAA is level 0, 0xCC is level 2 and irreversible, and any other value is level 1 (RM0351). A part left at level 0 can be read over the debug port. Even with protection set, a locked part guards that one chip. It does nothing for the same key sitting in your update file.

Recovery is the hard part. If your key is shared across a fleet that updates slowly, or not at all, you may be unable to rotate it, and the key you would use to fix things may be the one that leaked.

The same thinking applies to two related classes of flaw. Tokens in logs (CWE-532) become credentials printed over a debug UART that stays active in production. Weak certificate validation (CWE-295) becomes a TLS client left in a test configuration that accepts any certificate.

How to avoid it

Each of these is cheap to design in before the line is built, and expensive after. Weigh them against your own threat model. Better practice would be to:

1. Make provisioning a production step. Each unit gets its own credential at the factory, so one extraction costs you one unit. Decide which station does it, where the credentials come from, and who can see them. Then lock debug, and only after the flash is verified.
2. Keep the secret out of the application image. Store it in a separate protected region or a secure element, so the image you ship holds no secret at all.
3. Limit what each key can do. Give the device its own key, not a service account key. Let it reach only that unit's data, and let the server turn it off if it leaks.
4. Check the release artifact in CI. Scan every build, and fail it on a hit.

To scan, run something like this on the file you actually release, not your source tree, and on your update package as well as your flash image:

strings -n 8 release.bin | grep -iE 'key|token|secret|passw|BEGIN .*PRIVATE'

Any hit needs an explanation. A clean result doesn't clear you: strings finds text, and a raw 32-byte AES key isn't text. Check your map file too: it lists symbol names such as api_key, though not their values. Then look in your source for key arrays, and for anything your build injects at compile time.

In production, details matter: always verify behaviors against the official documentation for your specific part, core stepping, and toolchain. Silicon integrations vary widely.

Questions to reason through

• A signed update image contains an API key. What does signing protect, and what does it leave exposed?
• Someone extracts a device key and connects to your cloud broker. What should the broker still refuse to do?
• Why does a key shared across a fleet change the cost of a single extraction?
• Where on the production line should per-unit credentials be injected, and why lock debug only after the flash is verified?
• A strings scan of the release image comes back clean. What could it still miss?

Sources, check them yourself: CIVN-2026-0537, CVE-2026-121144, Rushlane. Goes deeper in Track 8.