AI-powered iOS application exposes LLM API credentials through network traffic

Applications of AI


A new in-depth security study reveals a critical and largely unaddressed class of vulnerabilities in the iOS app ecosystem. 64% of LLM-integrated applications actively leak API credentials over the network, allowing attackers to hijack paid AI inference.

A Wake Forest University team conducted the first in-depth empirical study targeting LLM API credential leakage in iOS applications, analyzing 444 LLM-integrated apps drawn from a pool of 1,092 manually evaluated candidates from the US App Store in October 2025.

To catch key leaks at runtime, a dynamic analysis framework was developed that intercepts outbound HTTPS traffic, applies provider-specific fingerprinting to extract candidate credentials, and actively validates each credential against the respective provider’s API. All without requiring source code access or binary decoding.

AI-powered iOS app exposes LLM API credentials

Of the 444 applications analyzed, 282 applications were observed to expose exploitable LLM API credentials in network traffic across at least 10 LLM providers and 5 cloud platforms.

The vulnerability affected apps across 13 categories, with Health & Fitness recording the highest breach rate at 47%, followed by Productivity at 40%. Widely adopted apps were also affected. The most popular vulnerable apps had over 2.3 million user ratings.

We identified three mechanisms by which credentials can be leaked from an iOS app into interceptable network traffic.

  • JWT-based token leakage (48%): Most common pattern. Developers employ backend proxy architectures to issue JSON web tokens to clients, but fail to enforce proper token expiration or authentication, making intercepted tokens freely reproducible.
  • Unauthenticated backend proxy access (33%): Developers correctly relocate raw LLM API keys to server-side proxies, but ignore implementing access controls on the proxy endpoint itself, creating an open relay that can be exploited without credentials.
  • Cleartext API key submission (19%): The most severe form of API key submission is when the API key is embedded directly in a cleartext HTTP request header or URL parameter. Once a single request is intercepted, unrestricted access to the developer’s entire LLM provider account is granted. In 52% of these cases, unique system prompts were exposed at the same time in the same request body.
LLM API credentials leaked through network traffic (Source: Arxiv)
LLM API credentials leaked through network traffic (Source: Arxiv)

LLMKeyLens operates as a man-in-the-middle (MITM) proxy framework installed on a physical iOS device.

Capture all outbound HTTPS traffic while testers interact with your app’s LLM features and apply provider-specific rules such as OpenAI awareness. sk-proj- key prefix on api.openai.com Alternatively, use Google Gemini’s query parameter format to extract credential suggestions.

For apps that use low level to bypass the system HTTP proxy NWConnection The LLMKeyLens API falls back to VPN-based transparent interception at the network layer and recovers traffic regardless of application-level proxy avoidance.

Only 32% of the apps analyzed had some form of anti-interception mechanism in place. Of these, HTTP proxy bypass was the most common single defense, but when countered by LLMKeyLens’ VPN layer fallback, the bypass rate was 81%.

Defense-in-depth, combining proxy bypass with custom payload encryption or WebSocket channels, reduced bypass rates to nearly zero, but only 30% of protected apps employed these combined strategies.

All 282 vulnerabilities were responsibly disclosed to developers through the App Store contact channel, with a 90-day remediation period. After three months, only 28% of vulnerable apps had patched reported issues. The remaining 72% is still exploitable.

  • 36 apps had unauthenticated backend proxies, and exposure alone did not prompt the architectural changes needed to enforce server-side access controls.
  • 30 apps exhibited fundamentally flawed JWT implementations, including missing tokens claiming a 100-year expiration date exp The field or server that accepted the token with the specified expiration time of 128 days.

One case study revealed that a Google Cloud Function backend accepted a fully unauthenticated POST request, returned a fully LLM-generated response that was billed to the developer’s OpenAI account, and remained fully open for 90 days after responsible disclosure.

Arxiv said the study calls for shared responsibility across developers, LLM providers and the App Store platform.

Data collection and classification workflow (Source: Arxiv)
Data collection and classification workflow (Source: Arxiv)

Developers should route all LLM API calls through authenticated server-side proxies, enforce strict access controls on backend endpoints, and revoke compromised credentials as soon as they are discovered.

LLM providers such as OpenAI, Anthropic, and Google Gemini should explicitly document client-side integration as an insecure pattern, publish reference implementations of authenticated proxy architectures, and introduce anomaly detection that flags keys that are accessed by an unusually large number of individual clients.

Apple’s App Store review process requires the integration of dynamic traffic analysis tools such as LLMKeyLens to detect leaked transport layer credentials before an app is published.

The findings reveal a systemic gap between real-world developer practices and secure LLM integration principles that must be jointly addressed by provider documentation, platform enforcement, and developer education to prevent continued economic and security harm.

Follow us on Google News , LinkedIn and X to Get More Instant UpdatesSet Cyberpress as a Preferred Source in Google.



Source link