The 10 Worst Documented Cases of Secrets Shipped Inside Distributed Application Artifacts

TL;DR #

• The single most severe documented case is the Symantec/Broadcom September 2022 analysis of 1,859 iOS/Android apps with hardcoded AWS credentials, in which an embedded AI-identity SDK leaked, in Symantec’s own words, “over 300,000 biometric digital fingerprints… across five mobile banking apps using the SDK” plus the full backend (API source code, AI models, root credentials) — all extractable directly from the shipped app binaries.
• Firmware cases rank near the top on raw scale: XiongMai/Mirai (hardcoded Telnet credentials in 500,000+ IoT devices, fueling record DDoS attacks) and the SEC Consult “House of Keys” study, in which “at least 230 keys are actively used by over 4 million Internet-connected devices.” Regulatory consequences are heaviest in the FTC firmware/IoT cases (D-Link, ASUS, TRENDnet) and the Lenovo Superfish desktop case, where the state settlement “mandated a financial payment of $3.5 million.”
• The defining lesson for a developer: any secret present in a distributed artifact — APK/IPA, .exe/.dll, firmware image, or client-side JS bundle — is recoverable with strings, a decompiler (jadx/Hopper), asar extract, or “view source.” Client-side restriction, key rotation, and a server-side broker are the only durable mitigations; obfuscation is not.

Key Findings #

• Scale leaders: Mobile SDK supply-chain leaks (Symantec 1,859 apps; CloudSEK Twitter 3,207 apps) and firmware key reuse (SEC Consult 4M+ devices; XiongMai 500,000+ devices) dominate on number of affected systems.
• Sensitivity leaders: The Symantec banking-SDK case (biometrics + full AWS root) and the mHealth study (PHI/PII for an estimated 23M users) unlock the most sensitive data classes. Lenovo Superfish enabled universal HTTPS interception.
• Regulatory/financial leaders: Only the FTC IoT cases and Lenovo produced binding enforcement (consent orders, 20-year audit regimes, a $3.5M Lenovo payment). Most API-key research disclosures produced no fines because researchers disclosed responsibly before exploitation.
• Recovery method is uniform and trivial: strings/jadx/Hopper on APK/IPA; firmware dump + filesystem extraction; “view source” / source-map reconstruction on SPAs; asar extract on Electron apps.

Details and Ranking #

The ten cases below are ranked by a composite of (1) scale of exposure, (2) sensitivity of what the secret unlocked, (3) whether a real breach/exploitation resulted, (4) regulatory/legal consequences, and (5) documentation quality. All meet the strict inclusion test: the secret was present in the distributed artifact (binary, APK/IPA, firmware image, or client JS bundle) and recoverable by someone holding only that artifact.

1. Symantec/Broadcom — 1,859 mobile apps with hardcoded AWS credentials; banking biometric SDK (iOS/Android, Sept 2022) #

What/where: Symantec’s Threat Hunter Team (researcher Kevin Watkins; commentary from principal editor Dick O’Brien) found 1,859 publicly available Android and iOS apps with AWS access tokens baked into the app packages — recoverable by unpacking the IPA/APK and decompiling (jadx for Android). 98% were iOS. 77% (1,431) contained valid AWS access tokens; 47% (873) granted full S3 access to millions of private files. The standout sub-case (in scope): A third-party AI Digital Identity SDK used by five iOS mobile banking apps embedded AWS credentials directly in the SDK shipped inside the apps. Those credentials exposed “private authentication data and keys belonging to every banking and financial app using the SDK,” plus the infrastructure server, API source code, AI models, and — in Symantec’s words — “over 300,000 biometric digital fingerprints… across five mobile banking apps using the SDK,” along with names and dates of birth. O’Brien told The Register: “Over 300,000 people’s fingerprints were exposed.” A second sub-case: 16 online gambling apps embedded a vulnerable library exposing full read/write root AWS credentials. A third: a B2B intranet SDK whose embedded AWS translation-service token instead granted “full unfettered access to all the B2B company’s AWS cloud services,” exposing intranet files for 15,000+ companies. Discovery/date: Symantec Threat Hunter Team, published Sept 1, 2022. Exposure/risk: Theft of biometric authentication templates (non-revocable), full cloud infrastructure compromise, source code and AI model theft. No public confirmation of a resulting criminal breach; Symantec notified affected parties. No fine disclosed. Why #1: Highest combination of sensitivity (irreplaceable biometrics + full root cloud access + financial data) and scale (1,859 apps, supply-chain propagation across unrelated developers via shared SDKs — 53% reused the same tokens found in other apps), with airtight primary documentation that the credentials were embedded in the shipped binaries.

2. XiongMai / Mirai — hardcoded Telnet credentials baked into IoT firmware (firmware, 2016) #

What/where: DVR/NVR/IP-camera firmware from Hangzhou XiongMai Technologies shipped with default credentials (notably root/xc3511) hardcoded into the firmware image, with a Telnet service hardcoded into the startup script /etc/init.d/rcS. The credentials could not be changed by users and the web UI was unaware they existed. Recoverable by dumping/extracting the firmware. Tracked as CVE-2016-1000245. Discovery/date: Flashpoint (lead researcher Zach Wikholm), October 2016, in the wake of the Mirai DDoS attacks. Exposure/risk: The Mirai botnet’s hardcoded 62-credential list (with root/xc3511 first) enslaved IoT devices into record DDoS attacks — against KrebsOnSecurity, OVH, and the Dyn DNS outage (Oct 21, 2016) that disrupted Twitter, Spotify, and PayPal. Flashpoint’s Shodan scan estimated 500,000+ vulnerable devices. XiongMai recalled fewer than 10,000 US webcams. Why #2: Massive real-world exploitation (not hypothetical), record-setting DDoS impact, a CVE, but lower data-sensitivity than #1 and no formal regulatory penalty.

3. SEC Consult “House of Keys” — private TLS/SSH keys embedded in firmware (firmware, 2015) #

What/where: SEC Consult (Stefan Viehböck) analyzed firmware images for 4,000+ device models from 70+ vendors and extracted 580+ unique private keys for HTTPS server certificates and SSH host keys baked directly into firmware images of routers, modems, IP cameras, and VoIP phones. Recoverable by extracting the firmware filesystem. (Example: a Broadcom-SDK certificate issued to “Daniel” at [email protected] appeared in firmware from Actiontec, Linksys, ZyXEL, and others.) Discovery/date: SEC Consult, published Nov 2015; follow-up “9 Months Later” Aug 2016. Coordinated via CERT/CC (VU#566724). Exposure/risk: “At least 230 keys are actively used by over 4 million Internet-connected devices. Around 150 of the HTTPS server certificates they recovered are used by 3.2 million devices and 80 of the SSH host keys are used by 900,000 devices.” Possession of the extracted private key enables impersonation, passive decryption, and man-in-the-middle attacks. Nine months later the problem had worsened: per SEC Consult, “the number of devices on the web using known private keys for HTTPS server certificates has gone up by 40% in the last nine months (3.2 million in November 2015 vs. 4.5 million now).” Why #3: Enormous scale and direct cryptographic compromise (MITM/decryption), well-documented with CERT coordination; lower because exploitation was demonstrated as feasible rather than confirmed at scale, and no penalties.

4. Lenovo / Superfish (Komodia) — root CA private key embedded in a shipped Windows binary (Windows desktop, 2015) #

What/where: Lenovo preinstalled “Superfish VisualDiscovery” adware (built on the Komodia SDK) on hundreds of thousands of consumer laptops beginning August 2014. The shipped Windows binary embedded a 1024-bit RSA root CA private key, identical across every machine, with the encrypting passphrase recoverable via the UNIX strings command. Per The Register (Feb 20, 2015): “Rob Graham from Errata Security searched the Superfish files using the good old UNIX command strings to pull out possible passwords to decrypt the software’s embedded private key. He discovered the passphrase ‘komodia’ in just a few hours.” Related Komodia issue: CVE-2015-2077. Discovery/date: Robert Graham / Errata Security, Feb 19–20, 2015; US-CERT alert Feb 20, 2015. Exposure/risk: Because every laptop carried the same root CA + private key, any attacker who extracted the key could forge trusted SSL certificates for any website and perform undetectable HTTPS MITM against affected users (banking, credentials, health). Errata Security: “anyone who wants to put in about 60 seconds of effort can forge a trusted SSL certificate for any website on the planet.” Regulatory/financial: FTC settlement (Sept 5, 2017) plus a 32-state Attorneys General settlement. Per Access Now: “The FTC settlement did not include a fine while the state settlement mandated a financial payment of $3.5 million,” with Lenovo accepting “20 years of biennial security audits” and an affirmative-consent requirement. The FTC noted no confirmed third-party exploitation. Why #4: The clearest Windows desktop in-scope case, universal HTTPS-interception severity, binding FTC + multistate enforcement with a dollar figure; lower than firmware cases on raw device count.

5. FTC v. D-Link — hardcoded “guest/guest” credentials in IP-camera firmware (firmware, 2017–2019) #

What/where: The FTC’s complaint (filed N.D. Cal., Jan 5, 2017) alleged D-Link hardcoded login credentials — username guest, password guest — into its IP-camera software/firmware, allowing unauthorized access to live camera feeds. Independent prior research (Core Security CORE-2013-0303) documented hardcoded RTSP backdoor credentials ?* baked into the firmware across 16+ D-Link camera models (CVE-2013-1599 through CVE-2013-1603). Discovery/date: FTC complaint Jan 2017; settlement July 2, 2019. Core Security 2013 for the technical antecedent. Exposure/risk: Unauthorized live-feed access to consumer/baby-monitoring/business cameras. The FTC alleged risk-of-harm rather than a confirmed mass breach. Settlement required a comprehensive security program, threat modeling, vulnerability testing, automatic firmware updates, a vulnerability-disclosure channel, and initial plus biennial third-party assessments for 10 years; the FTC lacks authority to levy fines in this posture. Why #5: Binding federal enforcement plus multiple CVEs and clear firmware-embedded credentials; lower on scale and confirmed-breach than the top firmware cases. (The related FTC actions against ASUS — default admin/admin, 12,900 storage devices exposed, Feb 2016 — and TRENDnet — ~700 camera feeds posted publicly, Sept 2013 — are the same class of IoT enforcement, though those credentials were default rather than purely hardcoded-and-unchangeable.)

6. CloudSEK BeVigil — 3,207 mobile apps leaking Twitter API consumer keys/secrets (iOS/Android, 2022) #

What/where: CloudSEK’s BeVigil engine found, per its report (via BleepingComputer), “3,207 leaking a valid Consumer Key and Consumer Secret for the Twitter API” hardcoded in the shipped APK/IPA (commonly in resources such as strings.xml); “230 apps were leaking all 4 Auth Creds” (Consumer Key/Secret + Access Token/Secret), enabling full account takeover. Recoverable by unpacking the app package. Discovery/date: CloudSEK, August 2022 (report shared with The Hacker News / BleepingComputer). Exposure/risk: Full takeover of associated (sometimes verified) Twitter accounts — read DMs, post/delete tweets, follow/unfollow, change profile — and the ability to assemble a “bot army” for misinformation/scam campaigns. Per CloudSEK, “57 of these companies had premium or enterprise subscriptions to the Twitter API.” Of the affected vendors, only Ford Motors responded and “deployed a fix on the ‘Ford Events’ app”; most others did not promptly remediate. No fine. Why #6: Large scale and account-takeover severity with strong documentation, but the data unlocked is social-media account control rather than financial/biometric/cloud-root data.

7. CloudSEK BeVigil — 40+ apps (100M+ installs) with hardcoded private AWS keys (iOS/Android, 2021) #

What/where: Analysis of ~10,000 apps found 40+ apps (cumulatively 100M+ downloads) with private AWS keys hardcoded in app packages — including major apps such as Adobe Photoshop Fix, Adobe Comp, Hootsuite, The Weather Channel, Club Factory, and Wholee. Keys typically sat in XML/config files (e.g., strings.xml) inside the APK. Discovery/date: CloudSEK, May 2021. Exposure/risk: In one analyzed app, the embedded AWS key reached multiple services and S3, exposing 88 buckets containing 10,073,444 files / 5.5 TB including source code, backups, user reports, and credential files — enabling deeper infrastructure compromise. Only ~17% of the 40 companies acknowledged the exposure. No confirmed criminal breach; no fine. Why #7: High aggregate install base and cloud-infrastructure severity with named brands; lower than #1 because no biometric/financial data class and no enforcement.

8. Knight Ink / Approov “All That We Let In” — hardcoded keys in mHealth app binaries (iOS/Android, 2021) #

What/where: Researcher Alissa Knight reverse-engineered 30 popular mHealth apps; 77% contained hardcoded API keys, tokens, and credentials in the app binary (extracted via static analysis with tools like MobSF and grep), and 7% contained hardcoded usernames/passwords. 114 hardcoded keys/tokens were found for services including Google, Stripe, AWS, Microsoft App Center, Branch.io, Cisco Umbrella, AppsFlyer, Facebook, and Salesforce; 7% were third-party payment-processor keys. Discovery/date: Knight Ink / Approov, published Feb 9, 2021. Exposure/risk: Per the report, “the average number of downloads for each app tested was 772,619, and Knight Ink estimates that the 30 apps evaluated expose some 23 million mHealth users, at a minimum.” The hardcoded keys are the in-scope finding: they ship inside the binary and unlock third-party services and payment processors on extraction. (Scope note: the report separately documents broken object-level authorization — BOLA — in the apps’ server-side APIs; that API-authorization weakness is an adjacent issue, not a secret embedded in the artifact, and the most damaging patient-record access combined the keys with those separate API flaws.) Why #8: Extreme data sensitivity (PHI-adjacent service access) and a credible 23M-user estimate, but apps were unnamed and the most damaging access combined keys with separate API flaws.

9. Truffle Security / CloudSEK / Quokka — Google “AIza” API keys in client JS and APKs that silently gained Gemini access (SPA/web + Android, 2026) #

What/where: Truffle Security (researcher Joe Leon) found ~2,863 live Google API keys (format AIza…) embedded in client-side JavaScript and APKs — originally deployed for benign services like Maps/Firebase per Google’s own guidance — that silently gained access to Gemini (Generative Language API) endpoints when that API was enabled on the project. Recoverable by “view source” on the SPA bundle or decompiling the APK (regex AIza[0-9A-Za-z\-_]{35}). CloudSEK’s BeVigil scanned the top 10,000 Android apps; Quokka found 35,000+ unique keys across 250,000 apps (39.5% contained Google API keys). Discovery/date: Disclosed to Google Nov 21, 2025; Google classified it “Single-Service Privilege Escalation, READ” (Tier 1) Jan 13, 2026; public disclosure Feb 25–26, 2026. Exposure/risk: With a valid key an attacker could access uploaded files and cached content via Gemini /files and /cachedContents, make arbitrary Gemini calls, and exhaust quota — billing the victim. One Reddit user reported $82,314.44 in charges over Feb 11–12, 2026 (vs. ~$180/month typical; this is a single user-reported figure, not an audited loss). Google began blocking leaked keys from Gemini and defaulted new AI Studio keys to Gemini-only scope. No fine. Why #9: Current, well-documented, large-scale, and notable as a case where official guidance (“API keys are not secrets”) was retroactively invalidated; lower because the unlocked data/financial impact per key is bounded relative to the top cases.

10. Rabbit R1 / Rabbitude — hardcoded keys confirmed inside the shipped APK (firmware/Android device, 2024) #

What/where: Independent reverse engineering (David Buchanan) of the shipped RabbitLauncher.apk — pulled from the Rabbit R1’s device firmware system partition — confirmed genuinely embedded client-artifact secrets: hardcoded device-auth strings and an RSA public key inside libbase.so, plus a check against two hardcoded APK signing keys. These are the in-scope secrets: present in the distributed firmware artifact and recoverable by anyone who unpacks it. Scope nuance: The reverse-engineering group Rabbitude separately reported (May 16, 2024; public June 25, 2024) hardcoded third-party keys for ElevenLabs, Azure, Yelp, Google Maps, and SendGrid. Those headline keys were reported as residing in Rabbit’s internal source code / backend — out of scope as a repo-style exposure — so this entry rests only on the device-auth and signing keys confirmed inside the APK. Discovery/date: Rabbitude, May–June 2024; David Buchanan APK analysis, 2024. Exposure/risk: The confirmed in-artifact secrets are device-auth strings and signing-key material — lower individual impact than a cloud-root or HTTPS-interception key. ~130,000 devices sold. Rabbit rotated keys only after public disclosure; no confirmed user-data theft; no fine. Why #10: High-profile and well-covered, but only the lower-impact device-auth/signing keys are confirmed inside the shipped artifact, so it ranks last among included cases. Included as an instructive boundary case for the developer audience: the most-cited Rabbit keys were backend-derived and therefore out of strict scope.

Honorable mentions (in scope, lower severity) #

• CloudSEK Razorpay payment keys (2021): ~10 apps embedded key_id+key_secret in the APK, enabling refund fraud and PII access (CloudSEK demonstrated a transaction of INR 1,82,813 with its payment ID); Razorpay deactivated all 10 keys by Sept 16, 2021.
• Bug-bounty SPA Stripe sk_live key (PlatformSecurity): a live Stripe secret key reconstructed from a JavaScript source map (via SourceMapper) yielded a $25,000 bounty; the Stripe balance API returned a large available balance, demonstrating impact.
• Twitter official-app consumer secret (2013): the consumer secret of Twitter’s own official clients was extracted from the app binary, allowing impersonation of the official apps — an early, widely cited proof that shipped client secrets cannot be kept secret.

Recommendations #

For a developer/architect, staged and concrete:

1. Immediately (triage): Treat every secret currently shipped in any client artifact — mobile binary, desktop EXE/DLL/Electron asar, firmware image, or SPA JS bundle — as already compromised. Inventory them now: run strings/jadx on your APK/IPA, asar extract on Electron builds, “view source” plus source-map reconstruction on your SPA, and a firmware dump on any embedded product. Search for high-signal patterns (AKIA, AIza[0-9A-Za-z\-_]{35}, sk_live_, private-key headers, default credential strings like xc3511).
2. Within days (contain): Rotate/revoke every discovered key. Rotation is mandatory, not optional — the Lenovo, Rabbit, and Razorpay cases all show that the exposed artifact remains in users’ hands indefinitely, so removing the key from the next build does nothing for shipped versions.
3. Structural fix (the only durable one): Do not embed secrets in client artifacts at all. Move third-party API calls behind a server-side broker/proxy that holds the secret and enforces per-user auth, rate limits, and scoping. For mobile, use platform key stores plus app-attestation (Play Integrity / App Attest) and inject build-time config via CI environment variables rather than committing it. For firmware, provision per-device unique credentials at manufacture and forbid unchangeable hardcoded logins (now legally required for consumer IoT sold in California under SB-327 and in the UK under the PSTI Act).
4. Scope every key (defense in depth): Apply least privilege — an AWS key for asset download should be an IAM role limited to one prefix in one bucket; a Google key for Maps should be restricted by API and by app/referrer so it cannot reach Gemini. The Symantec translation-token and Rabbit ElevenLabs cases were catastrophic precisely because over-broad keys reached far beyond their intended service.
5. CI/CD enforcement: Add secret scanning (TruffleHog, GitLeaks, or platform-native scanners) to the build pipeline and gate releases on it. Do not rely on obfuscation — it delays extraction by minutes, not meaningfully.

Benchmarks that would change the recommendation: If a credential genuinely must live client-side (e.g., a publishable/identifier-only token with no privileged scope and provider-enforced restriction), embedding is acceptable — but only if (a) the provider contractually treats it as public, (b) it is scoped so possession yields no privileged action, and (c) you monitor for anomalous use. The Google/Gemini case is the cautionary counterexample: a token documented as “public” was retroactively granted privileged scope, so prefer the broker pattern even for nominally public keys when the provider can change scope unilaterally.

Caveats #

• Scope discipline: Several widely cited “secrets” cases are explicitly out of scope and were excluded: the Uber 2016 AWS key (private GitHub repo), the 2022 Android OEM platform-certificate leak (build environment, not a shipped artifact), and apps that fetch tokens at runtime. The Rabbit R1 case is included only with an explicit nuance because its headline keys appear to be backend/source-derived; only the device-auth/signing keys are confirmed inside the shipped APK.
• Vendor-sourced figures: Much of the mobile-app evidence comes from security vendors with a commercial interest (Symantec/Broadcom, CloudSEK/BeVigil, Approov, Truffle Security, Quokka). Counts (1,859 apps; 3,207 apps; 300,000 fingerprints; 35,000 keys; 23M users) are the vendors’ own and were generally not independently audited, though several were corroborated by reputable outlets (The Register, BleepingComputer, The Hacker News, SecurityWeek).
• Risk vs. confirmed breach: Most cases document exposure and exploitability rather than a proven criminal breach. The FTC IoT complaints (D-Link, ASUS) explicitly alleged risk-of-harm, and Lenovo/Rabbit reported no confirmed third-party exploitation. The clearest real-world exploitation at scale is Mirai (XiongMai firmware).
• Anonymized subjects: The Symantec banking-SDK, mHealth (Knight Ink), and several CloudSEK sub-cases did not name the affected apps/companies, limiting independent verification of the specific victims even where the aggregate methodology is sound.
• The $82,314 Gemini charge is a single user’s Reddit-reported figure, not an audited loss, and is presented as such.