The 10 Worst Documented Cases of Secrets Shipped in Client Binaries

This is a Claude deep-research report, reproduced here as the evidence base for Your API Key Doesn’t Belong in the App. It is published as generated; sources are cited inline.

TL;DR #

The single most consequential case is Uber’s 2016 breach, where attackers found an AWS access key stored in code in a private GitHub repository, used it to pull 16 files from an S3 datastore, and exfiltrated data on 57 million riders and drivers — leading to a $148 million multistate settlement, an FTC consent order (File No. 152 3054 / Docket C‑4662), and the criminal conviction of Uber’s CSO (U.S. v. Sullivan, 3:20‑cr‑00337).
The pattern spans every platform: firmware (Mirai’s exploitation of immutable hardcoded Telnet passwords drove record DDoS attacks; D‑Link and ASUS drew FTC enforcement for “guest/guest” and “admin/admin”), mobile binaries (Symantec found 1,859 apps with hardcoded AWS keys, including a banking SDK exposing 300,000 biometric fingerprints), and client‑side code (CloudSEK found 3,207 apps leaking Twitter OAuth secrets; Truffle Security found Google API keys silently elevated to Gemini credentials).
The recurring root cause is architectural, not incidental: any secret shipped to a client — compiled binary, APK/IPA, or client‑side JavaScript — must be treated as already compromised, because it is extractable by strings, decompilation, or traffic interception, and broad IAM scope turns one leaked string into full infrastructure access.

Key Findings #

The cases below are ranked by a composite of (a) scale of exposure, (b) sensitivity of what the secret unlocked, (c) whether a real breach resulted, (d) regulatory/legal consequences, and (e) documentation quality. Cases with confirmed breaches and government enforcement rank highest; large‑scale scanning studies that demonstrated exploitability but did not always confirm exfiltration rank in the middle; the newest architectural‑class findings rank lower only because real‑world abuse is still emerging.

Details #

1. Uber Technologies — AWS key in code in a private GitHub repo (2016 breach) #

What it does: Ride‑hailing platform. The secret & where: An Uber engineer committed plaintext AWS access keys into code in a private GitHub repository. Engineers accessed GitHub via personal accounts without mandatory MFA and reused passwords exposed in prior breaches. Exposure & risk: Per the FTC’s own analysis, intruders “accessed Uber’s GitHub page using passwords that were previously exposed in other large data breaches, whereupon they discovered the AWS access key they used to access and download files from Uber’s Amazon S3 Datastore.” They downloaded 16 files containing unencrypted PII: approximately 25.6 million names and email addresses, 22.1 million names and mobile phone numbers, and 607,000 names and driver’s license numbers. Total impact: 57 million users and drivers. (Note: the FTC’s 2014 Uber matter involved a similar failure — an S3 datastore access key posted to a public GitHub repo, exposing ~110,000 drivers — establishing this as a repeat pattern.) Discovery/disclosure: Breach occurred October 2016; Uber discovered it on ~November 14, 2016 when an attacker demanded a payout. Uber paid the hackers $100,000 through its HackerOne bug‑bounty program and concealed the incident for roughly a year, disclosing publicly in November 2017. Consequences:

FTC consent order: File No. 152 3054 / Docket C‑4662; revised order issued October 26, 2018 (no monetary penalty; 20‑year third‑party assessment regime; comprehensive privacy program).
$148 million settlement with all 50 states + D.C. (September 26, 2018) — the largest multistate data‑breach settlement at the time.
DOJ criminal case: U.S. v. Joseph Sullivan (former CSO), No. 3:20‑cr‑00337 (N.D. Cal.), Judge Orrick. Convicted October 5, 2022 of obstruction (18 U.S.C. § 1505) and misprision of a felony (18 U.S.C. § 4); sentenced May 4, 2023 to three years’ probation and a $50,000 fine. Conviction affirmed by the Ninth Circuit, March 13, 2025.
The two extortionists (Brandon Glover and Vasile Mereacre) pleaded guilty in federal court.

Why #1: Only case here combining a confirmed mass‑scale breach, a hardcoded cloud key as the proximate cause, a nine‑figure penalty, and a criminal conviction of an executive.

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

What it does: XiongMai supplied white‑label firmware/components for IP cameras, DVRs, and routers used in hundreds of thousands of consumer devices. The secret & where: Default and hardcoded Telnet/SSH credentials baked into firmware (e.g., root/xc3511) that could not be changed by users, with Telnet active by default. The released Mirai source used a dictionary of 62 username/password lines (61 unique combinations) to brute‑force devices. Exposure & risk: Mirai scanned ports 23/2323, logged in with the hardcoded list, and conscripted devices into a botnet. Per Cloudflare’s measurements, Mirai infected over 600,000 vulnerable IoT devices at its peak. It produced record DDoS attacks:

OVH (Sept 2016): OVH founder Octave Klaba reported the botnet (“145,607 cameras/dvr”) was capable of >1.5 Tbps; the severest single attack reached ~799 Gbps, with peaks widely cited around 1 Tbps. CISA’s October 14, 2016 alert stated the OVH attack “was at least 1.1 terabits per second (Tbps), and may have been as large as 1.5 Tbps.”
Krebs on Security (Sept 20, 2016): Per Brian Krebs, “initial reports put it at approximately 665 Gigabits of traffic per second… analysis… suggests the assault was closer to 620 Gbps.” Akamai noted the prior record was 363 Gbps. CISA reported the author claimed “over 380,000 IoT devices were enslaved.”
Dyn DNS (Oct 21, 2016): knocked major sites offline across the U.S.

Discovery/disclosure: Malware discovered by MalwareMustDie in August 2016; source code released by “Anna‑senpai” on September 30, 2016; Krebs published analysis October 1, 2016. XiongMai’s vulnerable software ended up in at least half a million devices worldwide. Consequences: Creators Paras Jha, Josiah White, and Dalton Norman pleaded guilty (federal charges, 2017). Hundreds of thousands of devices remained permanently vulnerable because credentials were immutable in firmware. Mirai variants (Mozi, Gafgyt, etc.) remain active. Why #2: The hardcoded‑secret‑in‑firmware case with the largest measurable real‑world damage and a still‑active long tail.

3. Symantec/Broadcom 2022 — 1,859 mobile apps with hardcoded AWS credentials #

What it does: Broad study of iOS/Android apps and SDKs. The secret & where: Symantec’s Threat Hunter team found 1,859 apps with hardcoded AWS credentials (98% iOS). 77% contained valid AWS access tokens granting access to private AWS cloud services; 47% contained tokens granting full access to S3 buckets (sometimes millions of files). 53% reused the same tokens found in other apps — a supply‑chain SDK problem. Exposure & risk: Three documented case studies:

A B2B intranet/communications SDK with a hardcoded AWS token (intended only for the AWS translation service) that actually granted “full unfettered access to all the B2B company’s AWS cloud services,” exposing corporate data, financial records, and employee data for over 15,000 medium‑to‑large companies.
A third‑party AI digital‑identity SDK used by five iOS banking apps, exposing private authentication data, infrastructure source code, AI models, and over 300,000 biometric digital fingerprints plus PII (names, dates of birth).
A sports‑betting platform SDK used by 16 online gambling apps, exposing full AWS infrastructure with read/write root‑account credentials.

Named apps with hardcoded credentials included Pic Stitch (5M+ downloads, AWS), Crumbl (3.9M+ ratings), Eureka, Videoshop, Meru Cabs (Azure), Sulekha Business, ReSound Tinnitus Relief, and EatSleepRIDE (Twilio). Discovery/disclosure: Published September 1, 2022 by Symantec/Broadcom (researcher Kevin Watkins; Dick O’Brien commenting); covered by BleepingComputer, The Register, Dark Reading. Why #3: Highest sensitivity‑of‑secret (root cloud access, biometrics, banking) at large scale, though exfiltration was demonstrated as feasible rather than always confirmed in the wild.

4. D‑Link Systems — hardcoded “guest/guest” credentials in IP‑camera firmware (FTC 2017–2019) #

What it does: Consumer routers and Internet‑connected (IP) cameras. The secret & where: Hardcoded login credentials in D‑Link camera software — username and password both “guest” — plus mishandled private keys left on a public server for six months, command‑injection flaws, and mobile‑app credentials stored in cleartext on the device. Exposure & risk: Hardcoded “guest” credentials and other backdoors could allow unauthorized access to camera live video/audio feeds and enroll devices into botnets, despite D‑Link marketing “ADVANCED NETWORK SECURITY.” Discovery/disclosure: FTC complaint filed January 5, 2017 (FTC v. D‑Link Corporation and D‑Link Systems, Inc., 3:17‑cv‑00039‑JD, N.D. Cal.; FTC File 132 3157 / X170030). Consequences: Settlement filed July 2, 2019 — no monetary penalty and no finding of liability, but a comprehensive software‑security program with 10 years of biennial third‑party assessments. FTC: the flaws “included using hard‑coded login credentials on its D‑Link camera software with the easily guessed username and password, ‘guest.’” Why #4: Government enforcement with named primary sources; hardcoded credentials in firmware central to the complaint.

5. ASUSTeK Computer — default admin/admin and AiCloud flaws (FTC 2016) #

What it does: Consumer routers with AiCloud/AiDisk cloud‑storage features. The secret & where: Routers shipped with the same default login credentials on every device — username “admin,” password “admin” — with no requirement to change them, plus authentication‑bypass/path‑traversal flaws in AiCloud and an AiDisk FTP feature defaulting to “limitless access rights.” Exposure & risk: Attackers needed only the router’s (easily discoverable) IP address. In February 2014, attackers gained access to over 12,900 ASUS routers and connected storage devices; consumers’ files were indexed by search engines and used for identity theft. Discovery/disclosure: FTC complaint and consent agreement announced February 23, 2016 (FTC File 142 3156; Docket C‑4587); final Decision and Order July 28, 2016. Consequences: No penalty levied; 20‑year independent security‑audit regime. The FTC noted each future order violation “may result in a civil penalty of up to $16,000.” Why #5: Confirmed real‑world compromise plus government enforcement; ranks just below D‑Link on documentation density of the hardcoded‑secret element specifically.

6. Android platform signing certificates (Samsung, LG, MediaTek) leaked and used to sign malware (2022) #

What it does: OEM platform signing keys — the certificates used to sign the core “android” system application, which runs as the highly privileged android.uid.system. The secret & where: The platform private signing keys themselves leaked from OEMs. Any app signed with the same certificate can request android.uid.system, gaining system‑level access and sensitive permissions without user consent. Exposure & risk: Malware signed with these keys gains essentially unfettered access to the device — managing calls, installing/deleting packages, accessing user data. Samsung’s key signs Samsung Pay, Bixby, Samsung Account, the phone app, and more, so a malicious app could masquerade as a trusted system component across a huge installed base. Discovery/disclosure: Discovered and reported by Łukasz Siewierski (Google Android Security) via the Android Partner Vulnerability Initiative (AVPI); public ~December 2, 2022. Google listed 10 malware sample SHA256 hashes and told vendors to rotate platform certificates. Why #6: The most powerful class of secret (root‑of‑trust signing keys), with confirmed in‑the‑wild malware abuse, but the keys leaked from build environments rather than being extracted from a shipped binary — slightly outside the strict “shipped in the client” framing, hence mid‑rank.

7. CloudSEK — 3,207 mobile apps leaking Twitter API keys/OAuth secrets (2022) #

What it does: Apps integrating Twitter via OAuth. The secret & where: 3,207 apps leaked valid Twitter Consumer Key and Consumer Secret embedded in app packages (typically left over from testing). 230 apps leaked all four OAuth credentials, enabling full account takeover; 39 had all four valid. Exposure & risk: With all four credentials, an attacker could read DMs, retweet, like, delete, follow/unfollow, change profile pictures, and modify account settings on behalf of the app’s Twitter account. Some belonged to verified accounts; 57 apps held premium/enterprise API subscriptions ($149/month). CloudSEK warned the aggregate enabled a “bot army” for misinformation, phishing, and malware distribution. Discovery/disclosure: Published August 1, 2022 by CloudSEK (via BeVigil); covered by The Register, BleepingComputer, The Hacker News. (Notably, this echoes a 2013 incident in which the API keys for Twitter’s own official apps were extracted from the binaries.) Why #7: Very large count of exploitable OAuth secrets with full‑takeover capability, but per‑account impact is bounded versus cloud‑infrastructure or signing‑key compromise.

8. Knight Ink / Approov “All That We Let In” — mHealth apps with hardcoded keys + BOLA APIs (2021) #

What it does: 30 popular mobile health (mHealth) apps handling PHI/PII. The secret & where: 77% of the 30 apps contained hardcoded API keys (some non‑expiring), and 7% contained hardcoded usernames/passwords in cleartext; 7% of keys belonged to third‑party payment processors. Discovered API keys/tokens spanned Google, Stripe, AWS, Branch.io, Braze, Microsoft App Center, Salesforce, Vonage, and others. Separately, 100% of API endpoints were vulnerable to Broken Object Level Authorization (BOLA). Exposure & risk: Researcher Alissa Knight accessed patient reports, X‑rays, pathology reports, and full PHI records; changing one digit in an EHR identifier exposed other patients’ and family members’ records. 50% of accessed records contained names, SSNs, addresses, birthdates, allergies, and medications. Average 772,619 downloads/app; estimated 23 million mHealth users exposed at minimum. Discovery/disclosure: Published February 9, 2021 by Knight Ink and Approov. Why #8: High sensitivity (PHI, payment keys) and clear demonstration of access to live records, but apps were anonymized and no specific breach/enforcement followed.

9. Firebase misconfiguration cluster — client‑embedded config + open databases (Appthority 2018; Comparitech 2020; 2025) #

What it does: Thousands of Android/iOS apps using Google Firebase as a backend. The secret & where: Firebase configuration strings (API keys, project IDs, database URLs) are stored in client‑side code and trivially extracted by decompiling an APK or inspecting an iOS binary; combined with misconfigured security rules, the REST endpoint (append “/.json” to the database URL) returns the full database without authentication. Exposure & risk:

Appthority (2018): ~2,271 misconfigured databases exposed over 100 million records (113 GB), including 2.6 million plaintext passwords/IDs, 4M+ PHI records, 25M GPS records, 50,000 financial records, and 4.5M+ user tokens; Android versions alone had 620M+ downloads.
Comparitech / Bob Diachenko (2020): Of 515,735 apps analyzed, 4,282 leaked sensitive data; 11,730 had publicly exposed databases and 9,014 had write permissions (enabling data injection/corruption). Extrapolated to ~24,000 apps; affected apps had 4.22 billion combined installs. Exposed 7M+ emails, 1M+ passwords, 5.3M+ phone numbers, 6.2M+ GPS records.
2025 (Mike Oude Reimer / icex0): ~150 endpoints in top apps (some 100M+ downloads) exposed payment data, cleartext passwords, location, government‑ID photos, and high‑privilege API tokens (AWS root keys, GitHub, OpenAI).

Discovery/disclosure: Appthority May 2018; Comparitech May 2020; continued findings September 2025. Why #9: Enormous aggregate record counts and a textbook client‑side‑secret‑plus‑open‑backend pattern, but spread across thousands of small developers rather than a single high‑profile breach.

10. Truffle Security / CloudSEK — Google API keys silently elevated to Gemini credentials (2026) #

What it does: Web and mobile apps embedding Google API keys (Maps, Firebase) per Google’s own long‑standing guidance that such keys are “not secret.” The secret & where: Google API keys (AIza… format) embedded in client‑side JavaScript and mobile APKs. When a developer enables the Gemini (Generative Language) API on the same Google Cloud project, every pre‑existing unrestricted key silently gains access to Gemini endpoints — a retroactive privilege escalation. New keys also default to “Unrestricted.” Exposure & risk: An attacker who scrapes or decompiles the key can make arbitrary Gemini calls, read user‑submitted content/cached context via the Files API, exhaust quota, and rack up large bills. Truffle scanned the November 2025 Common Crawl (~700 TiB) and found 2,863 live vulnerable keys on public websites, including keys belonging to banks, security vendors, and Google itself; CloudSEK’s BeVigil found 32 keys across 22 Android apps with 500M+ combined installs. Discovery/disclosure: Reported by Truffle Security to Google November 21, 2025; initially dismissed as “Intended Behavior,” then reclassified as a Bug (Dec 2, 2025) and as “Single‑Service Privilege Escalation, READ” (Tier 1) on January 13, 2026; public disclosure February 25, 2026. CloudSEK published a parallel mobile‑app analysis. Consequences: Google added the reported keys to its leaked‑credential detection pipeline and began blocking exposed keys from Gemini; multiple developers reported large unauthorized bills. No regulatory action to date. Why #10: A novel, large‑scale architectural‑class flaw demonstrating the client‑side‑secret risk perfectly, but real‑world abuse and consequences are still emerging.

Honorable mentions (well‑documented, supporting the pattern) #

CloudSEK BeVigil AWS keys (2021): ~0.5% of 10,000 apps had hardcoded private AWS keys; 40+ apps with 100M+ combined downloads.
CloudSEK payment‑gateway keys (2021): ~5% of apps using Razorpay leaked key_id/key_secret (10 keys deactivated by Razorpay Sept 16, 2021).
CloudSEK Shopify tokens (2023): 21 apps with 22 hardcoded Shopify tokens, ~4M users at risk.
CISA ICS/medical‑device hardcoded‑password advisories (e.g., ICS‑ALERT‑13‑164‑01; Hughes WL3000 CVE‑2024‑39278 / CVE‑2024‑42495; Hillrom CVE‑2022‑26389) — recurring hardcoded‑credential CVEs in critical infrastructure and medical devices.

Recommendations #

For a developer building client‑facing software (mobile, desktop, web, or IoT):

Treat any secret shipped to a client as already public. A compiled .NET assembly, an APK/IPA, or minified JS can all be reversed with strings, ILSpy/dnSpy, jadx, or a proxy. This is the single threshold that should change behavior: if the secret reaches the device, assume it is extractable. Obfuscation only raises cost, never prevents extraction.
Move secrets server‑side. Mediate third‑party API calls (payment processors, cloud storage, AI APIs) through your own backend; never let the client hold the long‑lived credential. This is the fix Symantec, CloudSEK, and Truffle all converge on.
Scope every credential to least privilege. The Uber, Symantec‑B2B, and ASUS cases all turned a single key into infrastructure‑wide access because the IAM role/token was overly broad. A token for a translation service should not unlock all of S3.
Rotate and use short‑lived tokens. Use STS/temporary credentials, OAuth token exchange, or per‑device attestation. Rotate API keys on a schedule (CloudSEK recommends every ~6 months) and on any suspected exposure.
Scan binaries and repos in CI/CD. Use TruffleHog / git‑secrets / gitleaks pre‑commit and on every build; require code review and block merges containing key‑like strings. Uber’s 2016 breach was enabled partly by no MFA and credential reuse on GitHub — enforce MFA on all source‑control and cloud consoles.
For IoT/firmware: never ship immutable hardcoded credentials; force credential change on first boot; disable Telnet/unused services by default; provide a firmware update path and a vulnerability‑disclosure channel (all explicit FTC expectations from D‑Link/ASUS).
For platform/signing keys: store in an HSM or cloud KMS, never in a build tree; rotate immediately on any suspected compromise (the Android OEM lesson).

Benchmarks that change the plan: If a secret is genuinely public‑by‑design (e.g., a true client identifier), confirm via the vendor’s current documentation that it confers no privileged access — and re‑verify whenever you enable new services on the same cloud project (the Gemini lesson: privileges can change retroactively). If you cannot move a secret server‑side, require a second independent factor (device attestation) alongside it.

Caveats #

“Exposure” vs. “confirmed breach”: Several entries (Symantec 2022, CloudSEK Twitter, Knight/Approov mHealth, the Firebase studies, Truffle/Gemini) document demonstrated exploitability and scope, not always confirmed mass exfiltration by criminals. The text distinguishes these; only Uber, Mirai, ASUS, and (via signed malware) the Android OEM case have confirmed real‑world abuse.
Affected‑user counts are often estimates from the researchers (download counts, extrapolations), not audited figures.
The Android platform‑key and Mirai/XiongMai cases involve secrets leaked from build/firmware environments and immutable firmware credentials rather than strictly “extracted from a shipped app binary by a researcher.” They are included because they are the highest‑impact instances of the broader “secret embedded where the client/attacker can reach it” problem.
FTC D‑Link and ASUS settlements carried no monetary penalty and (for D‑Link) no finding of liability; the consequences were injunctive (audit regimes). The only nine‑figure dollar penalty in this report is the Uber multistate AG settlement, correctly attributed to the state AGs, not the FTC.
The “ASUS C‑4587” docket is consistent with FTC numbering and widely cited; the FTC’s matter page foregrounds File No. 142 3156. The ~12,900 figure and the $16,000‑per‑future‑violation cap are confirmed from FTC sources.
Mirai DDoS magnitudes vary by source (e.g., OVH reported as ~799 Gbps single‑attack up to >1.5 Tbps botnet capacity; Krebs as 620–665 Gbps). Exact peaks differ between the victims’ operators, Akamai, Cloudflare, and CISA; ranges are given rather than a single figure.