CWE-318, Cleartext Storage of Sensitive Information in Executable, is simple to state. A program ships with sensitive data written plainly inside the compiled file. Passwords, private keys, API tokens and license secrets are the usual suspects.
It hits anyone who distributes software: desktop apps, mobile apps, firmware, agents installed on customer machines. If the file leaves your control, assume someone will open it.
How it happens
A developer needs a credential at runtime and takes the shortcut of embedding it in source. The compiler turns that string into bytes inside the executable. Nothing about compilation hides it.
MITRE notes that attackers can reverse engineer binary code to obtain the secret, and that this is especially easy when the cleartext is plain ASCII. Even a value encoded so it is not human readable is not safe. Certain techniques can work out which encoding is in use and then decode it.
A typical vulnerable pattern:
/* Vulnerable: the key is a string literal in the binary */
static const char *ADMIN_PASSWORD = "s3cr3t-admin";
Running a strings tool against the compiled file prints that value.
What an attacker gains
The record lists one consequence: confidentiality, with the attacker reading application data. In practice that data is whatever you embedded. The observed examples show how bad it gets. CVE-2005-1794 describes a product that stored an RSA private key in a DLL and used it to sign a certificate, which allowed spoofing of servers and adversary in the middle attacks. CVE-2001-1527 is a case of administration passwords in cleartext in an executable.
How to find it
- Run a strings extraction over your release binaries and look for anything that resembles a password, key or token.
- Scan source and build artifacts for secret patterns before they ship.
- Review any code path that authenticates to a backend and ask where the credential comes from.
How to fix it
The fix is to stop treating the binary as a secure place.
- Remove the secret from the executable. Fetch it at runtime from a secrets manager or the operating system keystore.
- Give each install its own credential, issued at setup or activation, so one extracted value does not unlock everything.
- Prefer short lived tokens over long lived static ones, and rotate any secret that has already shipped.
- If a client must prove something to a server, use a per device key generated on the device rather than a shared one baked in.
Quick check
If I obfuscate the string, am I safe?
No. MITRE points out that encoded values can be decoded once the encoding is identified. Obfuscation slows a reader down. It does not protect the secret.
Does stripping symbols hide the key?
No. Data stays in the file. Stripping symbols removes names, not string contents.
