282 iOS Apps Found Leaking LLM API Credentials in Network Traffic

Researchers have uncovered a systemic LLM credential exposure problem in the iOS ecosystem, with 282 AI‑powered apps leaking exploitable API credentials and backend access mechanisms directly in network traffic.

The findings highlight widespread misuse of OpenAI, Gemini, and other LLM provider APIs in mobile apps and show that many issues remain unpatched even after responsible disclosure.

A team from Wake Forest University conducted the first in‑depth empirical analysis of LLM API credential leakage in iOS applications, using a dynamic traffic‑interception framework called LLMKeyLens.

Starting from 38,520 App Store listings, they curated a final dataset of 444 free iOS apps with confirmed, exercisable LLM features and then analyzed their runtime HTTPS traffic without jailbreaking devices.

LLMKeyLens operates as a man‑in‑the‑middle (MITM) proxy and VPN‑based capture stack, intercepting outbound traffic, fingerprinting LLM providers, extracting candidate credentials, and actively validating whether those credentials can be abused to obtain real LLM responses.

This dynamic approach lets the researchers bypass FairPlay DRM and encryption barriers that make static binary analysis on iOS impractical at scale.

282 iOS apps leaking credentials

Out of the 444 LLM‑enabled iOS apps, 282 (64%) were found to expose LLM‑related credentials or backend access mechanisms in network traffic. All of these were confirmed to be actively exploitable via credential replay at the time of testing.

Among these 282 apps, 146 cases (52%) were fully exploitable, either by leaking raw plaintext LLM API keys or by exposing unauthenticated backend proxies that accept arbitrary prompts.

The vulnerable apps span at least 13 App Store categories, with productivity, entertainment, lifestyle, education, utilities, and health & fitness among the most affected. Health & Fitness apps had the highest leakage rate (47%).

In contrast, productivity apps accounted for the largest absolute number of vulnerable apps, reflecting heavy client‑side LLM integration for writing, note‑taking, and translation features.

As reported by Arxiv, the study identifies three dominant credential‑leakage patterns in captured traffic, each with different exploitability characteristics.

• Plaintext LLM API keys (54 apps, 19%): Apps embed provider keys directly in HTTPS requests to OpenAI, Gemini and other LLM endpoints, usually in the Authorization header or URL parameters, making them recoverable from a single intercepted request and usable for arbitrary LLM calls. In 28 of these apps, proprietary system prompts are also exposed in the same request body, leaking core business logic alongside the key.
• JWT bearer tokens to backend proxies (136 apps, 48%): Apps move raw API keys to server‑side backends but issue JWTs or opaque bearer tokens to the client, which are then transmitted in Authorization headers to proxy endpoints that forward traffic to LLM providers. Many of these tokens remained valid for extended periods, and replaying captured tokens allowed attackers to invoke LLM services via the proxy, leading the authors to classify them as “limited exploitability”.
• Unauthenticated backend proxies (92 apps, 33%): Apps correctly hide API keys on the server but expose LLM functionality via backend endpoints that require no authentication at all, effectively creating open LLM relays that anyone can abuse once they learn the endpoint URL and request schema from intercepted traffic. These cases are classified as fully exploitable because they provide unrestricted LLM access without any credential barrier.

The leaking apps rely on a mix of direct LLM APIs, cloud platforms, and custom servers. The researchers found 54 apps leaking plaintext keys directly to LLM providers, with OpenAI accounting for 42 of those, followed by Gemini and a long tail of providers like DeepSeek, Mistral and others.

Another 67 apps proxy LLM calls through cloud platforms such as Firebase, Google Cloud Run and similar services. In comparison, 155 apps use custom developer‑maintained backends.

Across these architectures, exposed tokens and unauthenticated endpoints mean that provider‑side mitigations (e.g., rate limiting, anomaly detection) alone are insufficient because attackers can abuse proxy infrastructure without ever touching the underlying raw API key.

Only 143 of the 444 evaluated apps implemented any client‑side defense against HTTP proxy interception, such as proxy bypass, custom encryption, WebSocket channels or anti‑debugging logic.

Even among those, the most popular single mechanism, HTTP proxy bypass, had an 81% bypass rate under LLMKeyLens, which fell back to VPN‑based transparent interception to capture traffic at the network layer.

Layered defenses combining proxy bypass with custom encryption or WebSockets performed much better, cutting pipeline bypass rates to around 7%. However, such multi‑mechanism deployments appeared in only about 10% of apps.

The authors note that this gap suggests developers are prioritizing ease of integration over robust credential protection in LLM‑powered apps.

Remediation after disclosure

The team notified developers of all 282 vulnerable apps, providing evidence and mitigation guidance, then re‑tested the same traffic patterns 90 days later.

Only 78 apps (28%) showed clear remediation, typically by revoking exposed API keys, enforcing authentication on previously open proxies, or ensuring JWT expirations are correctly enforced server‑side.

However, 66 apps (23% of the original 282) remained exploitable after the disclosure window, either because no meaningful changes were made or because authentication was implemented incorrectly.

In some of the worst cases, JWTs were issued without expiration claims or with validity periods of up to 100 years, and some backends continued to accept JWTs long after their exp timestamps had passed.

The study underscores that simply “hiding the key on the server” is not enough; secure LLM integration must combine server‑side key storage with strong, enforced authentication and token lifecycle management. Developers are urged to:

• Route all LLM calls through authenticated backend proxies, never from the iOS client using static API keys or long‑lived tokens.
• Enforce proper JWT semantics: short lifetimes, mandatory exp claims, and strict server‑side validation rejecting expired or malformed tokens.
• Avoid unauthenticated LLM relay endpoints; every proxy call should be tied to a verified user or app instance.
• Layer traffic‑protection mechanisms (e.g., certificate pinning, WebSocket plus encryption) when feasible, rather than relying on proxy bypass alone.

The authors also recommend that LLM providers publish secure reference architectures for mobile app integrations and that Apple incorporate automated traffic‑analysis checks, such as LLMKeyLens, into App Store review to catch credential leakage before LLM‑powered apps reach end users.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.