Two-thirds of AI iOS apps leak their LLM credentials in plain network traffic

What is this?

On June 10, 2026 (revised June 23), researchers from Wake Forest University published Mind your key, the first in-depth empirical study of LLM API credential leakage in iOS applications (arXiv:2606.12212). They built a dataset of 444 AI chatbot apps, filtered from 1,092 candidates on the US App Store, and inspected each one’s network traffic with a purpose-built tool they call LLMKeyLens. The result: 282 of the 444 apps — nearly two-thirds — expose usable LLM credentials that let anyone send model requests on the developer’s account and stick them with the bill.

What makes the finding uncomfortable is how little effort the extraction took. LLMKeyLens needs neither source code nor binary decryption; it simply watches the traffic an app already sends and pulls the secret out as it goes by. The credentials span at least ten providers, with OpenAI the most common, across thirteen app categories.

How it works

When a mobile app embeds a provider key so it can call a service like OpenAI or Gemini directly, that key travels with every request the app makes. Anyone who can observe the traffic — the app’s own user, someone on the same network, or a proxy — can read it. The study sorts the 282 leaking apps into three patterns.

The most common, at 48% (136 apps), is replayable token leakage. These apps do the theoretically safer thing and hand out short-lived tokens instead of the raw key, but the tokens leak in the same traffic and were usually still valid when captured. Some were not short-lived at all: one popular app set its token to expire in the year 2125 — effectively a hundred-year pass — and another app’s supposedly one-hour token still worked 128 days after it should have died.

The second pattern, 33% (92 apps), is an unauthenticated backend proxy: the app routes requests through a server that answers anyone, with no check on who is asking. That is an open relay to a paid AI account, and there is no key to steal because none is required.

The third, 19% (54 apps), is plaintext key transmission — the raw provider key sent in the open, readable from a single captured request. For 28 of those 54 apps, the same request also revealed the app’s hidden system prompt, exposing the product’s behind-the-scenes instructions alongside its billing credential.

Why it matters

A leaked LLM key is not an abstract risk; it is a metered one. Stolen keys feed the practice the industry calls LLMjacking, and Sysdig has estimated a worst-case burn of more than $46,000 a day in model charges on a single compromised account. Beyond the bill, an open proxy or exposed key hands an attacker free frontier-model inference, and a leaked system prompt can reveal proprietary logic and hint at further abuse paths.

The persistence is the worst part. The researchers notified all 282 developers and waited three months; only 28% had clearly fixed the problem, 23% were still wide open with the leaked access working, and the rest had gone offline or returned errors. This mirrors earlier findings on Android — the 2025 LM-Scout study automatically broke into 120 apps using the same class of insecure wiring — so the AI rush has not changed the habit, only raised the cost of it. The authors stress the two-thirds figure is a floor: many apps blocked interception outright, and the study covered only the US App Store in late 2025.

Defenses

The core fix is old advice that too few teams follow: the provider key should never live in the client.

• Proxy every model call through your own backend. The app talks to your server; your server holds the provider key and talks to OpenAI, Gemini, and the rest. The key never ships in the binary or crosses the wire to the device.
• Authenticate the caller at that backend. A relay that answers anyone is an open relay. Tie each request to an authenticated user or device identity and reject the rest.
• Issue tokens that are actually short-lived and scoped. Enforce real server-side expiry, bind tokens to a user and a purpose, and reject expired or replayed tokens instead of trusting a client-supplied clock.
• Add spend caps, per-user quotas, and rate limits. These bound the damage when a credential does leak and buy time to respond.
• Watch for anomalies and revoke fast. A key that suddenly serves thousands of devices is a signal. Rotate keys on any suspicion — and confirm the old one is truly revoked, since prior audits found developers routinely leave removed keys live.

The study also puts responsibility upstream: it asks providers to label client-side keys as unsafe in their documentation and to flag keys used from implausibly many devices, and it asks Apple to screen for this pattern during App Store review.

Status

Item	Value (Wake Forest, June 2026)
Apps analyzed	444 (filtered from 1,092)
Apps leaking usable credentials	282 (~64%)
Replayable token leakage	48% (136 apps)
Unauthenticated backend proxy	33% (92 apps)
Plaintext key transmission	19% (54 apps)
Plaintext apps also leaking system prompt	28 of 54
Providers affected	≥ 10 (OpenAI most common)
Fixed 3 months after disclosure	28%
Still exploitable at re-test	23%
Detection tool	LLMKeyLens (traffic interception, no binary decryption)

Key dates: June 10, 2026 — first submission of the study. June 23, 2026 — revised version. June 30, 2026 — wider reporting. Scope caveat: US App Store, late 2025; the two-thirds rate is a lower bound.