Estudo encontra credenciais expostas em 282 apps de iOS com integração LLM e revela falha sistêmica do ecossistema

Pesquisadores da Wake Forest University publicaram um levantamento abrangente sobre vazamento de credenciais em aplicativos iOS com integração a modelos de linguagem (LLMs): de 444 apps analisados, 282 (cerca de 64%) expuseram tokens de autenticação, chaves de API em texto plano ou endpoints de backend sem autenticação. O estudo cobre 13 categorias da App Store e mostra que o problema atinge tanto apps obscuros quanto produtos com mais de 2,3 milhões de avaliações. Após 90 dias de divulgação responsável, apenas 28% das aplicações vulneráveis remediaram o problema, enquanto 23% seguem exploráveis por inação ou erro estrutural de implementação.

O que aconteceu

O grupo da Wake Forest filtrou mais de 38 mil listagens da App Store norte-americana até isolar 444 aplicativos com funcionalidade comprovada de LLM, abrangendo categorias como produtividade, entretenimento, lifestyle, educação, utilidades e saúde e fitness. Sobre esse conjunto, os pesquisadores realizaram análise estática do binário Mach-O, inspeção de strings, interceptação de tráfego de rede via proxy controlado e teste manual de comportamento contra os endpoints descobertos.

O resultado é mais sistêmico do que um susto pontual. Em 26% do total analisado, foram encontradas credenciais ou mecanismos de acesso exploráveis. Quinze por cento dos apps vulneráveis tinham mais de mil avaliações, e o caso mais notável agregava mais de 2,3 milhões. O mercado de LLM em mobile alcançou 17 bilhões de downloads em 2025, representando 13% de todos os downloads de aplicativos, segundo dados citados no estudo, o que torna o vetor materialmente relevante.

Como o vazamento se materializa

O padrão técnico identificado se divide em três modalidades. Em 136 aplicativos, tokens de autenticação ficavam embutidos no binário ou trafegavam em formato recuperável durante o handshake com o backend, permitindo que um atacante os extraísse via interceptação simples com mitmproxy ou ferramentas semelhantes. Em 92 casos, o backend não exigia autenticação alguma para chamadas de inferência LLM, deixando o endpoint aberto para qualquer cliente que descobrisse a URL. Em 54 aplicativos, chaves de API de provedores como OpenAI, Anthropic ou Google em texto plano estavam armazenadas no app, e em 28 desses casos os system prompts proprietários também vazavam — expondo lógica de negócio, instruções de moderação e configurações de comportamento que muitas vezes representam o diferencial comercial do produto.

O quadro por arquitetura é instrutivo. Cento e cinquenta e cinco apps mantinham backend próprio operado pelo desenvolvedor; 67 usavam plataformas de cloud como Firebase, Google Cloud Run ou AWS; 60 conversavam diretamente com APIs de provedores LLM. As taxas de vazamento foram, respectivamente, 55%, 23% e 21% — desmontando a noção comum de que adotar uma camada de proxy próprio resolve o problema. A arquitetura intermediária só protege se houver implementação correta de autenticação, autorização e rate limiting, o que claramente não é a regra.

“O vazamento de chaves de API de LLM é uma questão sistêmica e generalizada no ecossistema iOS, afetando 26% dos Apps analisados em categorias e perfis de desenvolvedor diversos. O impacto da vulnerabilidade se estende de apps de nicho a aplicativos populares com centenas de milhares de usuários.” — Pesquisadores da Wake Forest University

Riscos concretos para usuários, desenvolvedores e provedores

• Cobrança indevida: chaves expostas de OpenAI, Anthropic e Google podem ser usadas em escala por terceiros, gerando faturas em milhares de dólares cobradas do desenvolvedor original.
• Exfiltração de system prompts e jailbreak comercial: 28 apps tiveram suas instruções de comportamento expostas, permitindo clonagem do produto e contorno de filtros.
• Risco para usuários: backends sem autenticação podem ter retornado dados de outros usuários se não houver isolamento de sessão, e prompts maliciosos podem manipular respostas exibidas a vítimas legítimas.
• Compliance: chaves vazadas que processam dados sensíveis em saúde e fitness (categoria com maior taxa de vazamento) tendem a configurar incidente reportável sob LGPD, GDPR e HIPAA equivalentes.
• Vetor de abuso de modelo: agentes maliciosos costumam usar chaves roubadas para enviar conteúdo proibido, gerar campanhas de spam ou desinformação, e burlar limites de uso responsáveis.

Análise: a dívida técnica esquecida da era LLM

O estudo de Wake Forest articula um padrão que vem sendo repetido a cada nova onda tecnológica: a pressão para entregar funcionalidade vence o rigor de segurança, e práticas básicas reconhecidas há quinze anos no Mobile OWASP Top 10 são reaplicadas como se fossem novas. Hardcoding de credenciais em aplicativos móveis é o segundo item da lista MASVS desde a primeira versão, e proxy pattern para chaves de provedor é recomendação documentada pela própria OpenAI desde 2023. Ainda assim, o estudo mostra um cenário em que 64% dos apps com LLM analisados falham no básico.

Há um agravante específico do ciclo LLM. Diferentemente de uma chave de API de geolocalização, cuja exploração tem teto de custo previsível, uma chave de provedor LLM exposta pode gerar despesa exponencial em horas via prompts caros, em modelos como GPT-4o, Claude Sonnet 4.6 ou Gemini Pro. O modelo de cobrança por token, sem cap padrão no painel do provedor, transforma uma negligência de configuração em incidente financeiro material. Para empresas brasileiras, a recente migração de chatbots e assistentes corporativos para mobile coincide com esse pico de exposição, e poucos times de mobile no país têm pipeline de revisão de binário antes da publicação na App Store.

A resposta dos desenvolvedores reforça a tese estrutural. Noventa dias após o disclosure, apenas 28% das equipes notificadas rotacionaram a chave ou implementaram controle de acesso. Trinta e seis aplicativos sequer responderam, e outros trinta tentaram corrigir com implementações falhas. O ecossistema atual coloca a responsabilidade primária sobre o desenvolvedor individual, sem que os provedores de LLM ofereçam ferramentas de detecção de chave em uso fora do bundle esperado, fingerprint de cliente ou bloqueio automático ao detectar uso em IP residencial não associado ao desenvolvedor.

Recomendações práticas para desenvolvedores e equipes de segurança

• Nunca inclua chaves de API de provedores LLM no binário do app. Use sempre um backend proxy autenticado por sessão de usuário, com tokens efêmeros emitidos por seu próprio serviço de identidade.
• No backend proxy, implemente rate limiting agressivo por usuário, alertas de gasto e cap diário por conta, fechando o ciclo financeiro de abuso.
• Habilite ferramentas de cofre de segredos no pipeline de CI/CD (HashiCorp Vault, AWS Secrets Manager, Doppler) e proíba commits de chaves via pre-commit hooks como gitleaks, trufflehog ou detect-secrets.
• Rotacione chaves periodicamente e gere alertas em uso anômalo: volumes inesperados, geografias não previstas e horários atípicos.
• Realize análise estática do binário Mach-O antes do upload na App Store, buscando strings sensíveis e padrões de chave (sk-, AKIA, AIza, etc.).
• Implemente intercept proxy em ambiente de QA com mitmproxy ou Charles para verificar exatamente o que o app envia em runtime, não apenas o que está no código fonte.
• Em ambientes corporativos, exija revisão de mobile com MASVS antes da publicação, e mantenha inventário de quais apps consomem qual provedor LLM, com sua respectiva chave.
• Para usuários finais com preocupação de privacidade, considere que dados enviados a apps com integração LLM podem trafegar por endpoints inseguros e prefira soluções que documentam claramente a arquitetura.

Fonte: Help Net Security