Hardcoded credentials in apps and devices (CWE-798): why they leak and what to do

What it is. MITRE's Common Weakness Enumeration entry CWE-798 describes a product that contains hard-coded credentials, such as a password or cryptographic key.

Two variants

Inbound: the product checks logins against a built-in set of credentials, typically a default admin account with a fixed password. MITRE notes this password is the same on every installation, usually cannot be changed or disabled without patching, and can be hard for administrators to detect.

Outbound: the product connects to another system and carries the credentials for that back end inside itself. MITRE says this applies to front ends that authenticate to a back-end service; a mobile app holding a database or API password is the classic case.

Why it is so serious

MITRE says that if hard-coded passwords are used it is almost certain malicious users will gain access, and that client-side software is an even bigger threat because extracting a password from a binary is usually very simple. Because every copy shares the same secret, one published password opens every deployment, which MITRE notes enables mass attacks such as worms. Shipping an app to the public means shipping the secret to the public.

For teams that build software (MITRE's mitigations, summarised)

Keep outbound credentials out of the code, in a strongly protected configuration store or database, and protect the key that protects them. For inbound logins, replace built-in defaults with a first-login mode that forces a unique strong password or key. If a fixed credential truly cannot be removed, limit who can reach the feature that uses it, for example console-only rather than over the network. Store password hashes, not passwords, using strong one-way hashes with a random salt per hash.

Desk practice on top of that (not MITRE text): a public mobile app should never hold a credential that reaches a shared back-end data store directly. Give the app per-user, short-lived tokens issued by your own service, scope them to that user's data, and run secret scanning on source and on the built app package before release.

For buyers and operators

Ask suppliers whether any product, firmware or app contains fixed credentials, and how they are rotated. Change every default password at install (see default passwords). Treat a vendor advisory about a hardcoded credential as urgent: patch, and assume the old secret is public.

On the day one is found in your product

1. Revoke or rotate the exposed secret first; a new app release does not remove the secret from copies already downloaded. 2. Work out what the credential could reach, and invalidate anything it exposed, such as stored session tokens or API keys. 3. Check logs for use of the credential before the report; if you cannot, record that gap honestly. 4. If personal information could have been reached, start your data breach assessment (see the NDB clock page). 5. Publish a working security contact so the next researcher can reach you directly.

Case study

In November 2026 a researcher told TechCrunch that a password in Wyndham's Android app opened an internal customer database; Wyndham told TechCrunch it addressed the issue and had no evidence of unauthorized access (see the CyberStack card).