SAP expõe credenciais OAuth2: o risco oculto dos SDKs

A SAP, gigante alemã de software empresarial, acaba de admitir uma falha de segurança que recebeu a nota máxima de gravidade: CVSS 10.0. O problema, rastreado como CVE-2026-89111, afeta o Cloud SDK para Python, uma ferramenta usada por desenvolvedores para integrar aplicações à plataforma SAP Business Technology Platform (BTP). Em termos simples, a falha permitia que um invasor roubasse as credenciais OAuth2 de uma aplicação, redirecionando-as silenciosamente para um servidor sob seu controle. Mas, como sempre, o comunicado oficial esconde mais do que revela. Vamos destrinchar o que realmente está em jogo.

O que a SAP não está contando sobre a falha

O boletim de segurança da SAP, publicado em 13 de outubro, descreve a vulnerabilidade como um Server-Side Request Forgery (SSRF). Na prática, quando uma aplicação multi-tenant passava um subdomínio de tenant ao SDK, o código não validava adequadamente esse valor. Um invasor que controlasse o subdomínio podia manipular a URL de autenticação, fazendo com que o SDK enviasse o client ID e o client secret — as credenciais da aplicação — para um endpoint malicioso.

A correção veio na versão 0.45.2, lançada em 21 de agosto, que adicionou uma verificação para rejeitar subdomínios que não fossem nomes simples. Mas aqui está o detalhe que a SAP preferiu não destacar: seis versões posteriores (0.53.0 a 0.55.0), publicadas entre 10 e 18 de setembro, não aplicavam essa verificação em todos os casos. Especificamente, quando a aplicação usava o módulo Destination service, a checagem era ignorada. Isso significa que, durante uma janela de tempo, desenvolvedores que atualizaram para versões supostamente corrigidas continuaram vulneráveis sem saber.

Além disso, as versões 0.36.1 e 0.36.2, da linha mais antiga, também não possuíam a verificação. O boletim da SAP lista apenas versões abaixo de 0.45.2 como afetadas, mas testes independentes mostraram que as seis versões intermediárias falharam em 9 dos 11 testes de segurança criados pela própria SAP. A empresa não esclareceu se essas versões estão cobertas pelo CVE, deixando uma lacuna perigosa para quem confiou no histórico de releases.

Leia também: Vazamento de Senhas Reutilizadas: Riscos Corporativos para entender como credenciais comprometidas podem escalar rapidamente em ambientes empresariais.

Por que essa falha é um prato cheio para ataques de phishing

O roubo de credenciais OAuth2 não é apenas um problema técnico; é a porta de entrada para ataques de phishing sofisticados. Com o client ID e o client secret em mãos, um invasor pode se passar pela aplicação legítima, enganando usuários e sistemas para obter ainda mais acessos. Pense no cenário: um funcionário recebe um e-mail falso, aparentemente enviado por um sistema interno confiável, pedindo para “reautenticar” suas credenciais. Esse e-mail pode ser gerado a partir da identidade roubada da aplicação, tornando a fraude quase indistinguível da realidade.

O phishing é uma das táticas mais eficazes porque explora a confiança. E quando as credenciais de uma aplicação corporativa são comprometidas, o invasor ganha um disfarce perfeito. Ele não precisa mais clonar um site ou criar um domínio parecido; ele usa a própria identidade da aplicação para solicitar tokens de acesso. Isso pode levar ao acesso não autorizado a dados sensíveis, como informações de clientes, registros financeiros ou propriedade intelectual.

Além disso, a falha da SAP demonstra como vulnerabilidades em SDKs — ferramentas amplamente utilizadas por desenvolvedores — podem ter um efeito cascata. Cada aplicação que usa o SDK afetado torna-se um vetor potencial. E como muitos desenvolvedores confiam cegamente nas bibliotecas que utilizam, a verificação de segurança muitas vezes fica em segundo plano.

Outro ponto relevante: a IA está reescrevendo código, mas também criando novas falhas. Leia nosso artigo IA Reescreve Código, Mas Cria Novas Falhas de Segurança para entender como a automação pode introduzir vulnerabilidades semelhantes se não for supervisionada.

A responsabilidade das empresas: transparência ou conveniência?

A SAP corrigiu a falha em agosto, mas só divulgou o problema em outubro — 53 dias depois. Durante esse período, quantas aplicações continuaram vulneráveis? O comunicado não menciona se houve exploração ativa, mas a ausência de evidência não é evidência de ausência. A empresa credita um usuário do GitHub, SunandM, pela descoberta, mas não detalha como a falha foi reportada ou se houve coordenação com clientes antes da divulgação pública.

Essa prática de divulgação retardada é comum na indústria, mas levanta questões éticas. As empresas muitas vezes priorizam a própria imagem em detrimento da segurança dos usuários. No caso da SAP, a falha estava presente desde o primeiro lançamento do SDK em PyPI, em 16 de março. Ou seja, durante meses, qualquer aplicação multi-tenant usando o SDK estava potencialmente exposta. E o pior: a correção inicial foi listada nas notas de versão como “Bug Fixes”, sem menção a segurança. Isso sugere que a SAP não considerou a gravidade do problema na época, ou pior, tentou minimizá-lo.

Como analista crítico de privacidade, questiono: quantas outras falhas semelhantes estão escondidas em SDKs populares? A dependência de bibliotecas de terceiros é um risco inerente ao desenvolvimento moderno, mas a responsabilidade de garantir a segurança não pode ser terceirizada. As empresas precisam ser mais transparentes sobre vulnerabilidades, com prazos claros de divulgação e orientações práticas para mitigação.

O impacto real para empresas e usuários

O impacto de uma falha como essa vai além do roubo imediato de credenciais. Imagine uma aplicação de e-commerce que usa o SAP Cloud SDK para autenticar clientes. Se as credenciais OAuth2 forem comprometidas, o invasor pode acessar a base de dados de clientes, incluindo informações pessoais e financeiras. Isso pode resultar em vazamentos de dados em massa, com consequências legais e reputacionais severas.

Além disso, a falha pode ser usada como parte de um ataque maior. Por exemplo, um invasor pode usar as credenciais roubadas para enviar e-mails de phishing direcionados a funcionários da empresa, fingindo ser um sistema interno. Isso aumenta a taxa de sucesso do ataque, pois os destinatários confiam na origem aparente.

Para os usuários finais, o risco é indireto, mas real. Seus dados podem ser expostos sem que eles tenham qualquer culpa. E quando isso acontece, as empresas raramente assumem a responsabilidade de forma proativa. Muitas vezes, os afetados só descobrem o vazamento meses depois, quando seus dados já estão sendo vendidos em fóruns clandestinos.

Como se proteger: lições práticas

Diante desse cenário, é essencial adotar uma postura proativa de segurança. Aqui estão algumas orientações práticas:

• Atualize imediatamente: Se você usa o SAP Cloud SDK para Python, verifique a versão. As versões seguras são 0.45.2 a 0.52.2 e 0.55.1 a 0.58.4. Evite as versões 0.53.0 a 0.55.0 e qualquer versão abaixo de 0.45.2.
• Valide manualmente: Mesmo com a correção, implemente uma validação adicional no seu código. Compare cada subdomínio de tenant com uma lista de tenants registrados antes de passá-lo ao SDK.
• Monitore suas credenciais: Se você suspeita que suas credenciais OAuth2 foram comprometidas, revogue-as imediatamente e gere novas. Considere usar ferramentas de monitoramento de identidade para detectar usos não autorizados.
• Eduque sua equipe sobre phishing: A falha da SAP pode ser explorada em conjunto com e-mails falsos. Treine seus funcionários para reconhecer sinais de phishing, como URLs suspeitas, erros gramaticais e solicitações urgentes de informações.
• Adote uma mentalidade de zero confiança: Não confie cegamente em bibliotecas de terceiros. Revise o código-fonte sempre que possível e mantenha-se informado sobre vulnerabilidades conhecidas.

Lembre-se de que a segurança é um processo contínuo. A falha da SAP é apenas um exemplo de como vulnerabilidades em componentes aparentemente inofensivos podem ter consequências graves. Fique atento a atualizações e comunicados de segurança, e não hesite em questionar as empresas quando a transparência for insuficiente.

FAQ: Perguntas Frequentes sobre a Falha da SAP

O que exatamente é a falha CVE-2026-89111?

É uma vulnerabilidade de Server-Side Request Forgery (SSRF) no SAP Cloud SDK para Python. Ela permitia que um invasor controlasse o subdomínio de tenant para redirecionar as credenciais OAuth2 da aplicação para um servidor malicioso, resultando no roubo do client ID e client secret.

Quais versões do SAP Cloud SDK são afetadas?

Oficialmente, a SAP lista versões abaixo de 0.45.2 como afetadas. No entanto, testes independentes mostraram que as versões 0.53.0 a 0.55.0 também não aplicavam a verificação em todos os casos (especificamente para o módulo Destination service). As versões 0.36.1 e 0.36.2 também são vulneráveis. As versões seguras são 0.45.2 a 0.52.2 e 0.55.1 a 0.58.4.

Como posso saber se minha aplicação foi comprometida?

Não há uma maneira direta de saber se suas credenciais foram roubadas, a menos que você monitore ativamente o uso delas. Recomenda-se verificar logs de autenticação em busca de solicitações suspeitas, como tentativas de acesso de IPs desconhecidos ou horários incomuns. Se houver qualquer suspeita, revogue as credenciais imediatamente.

A SAP divulgou a falha de forma adequada?

Não, na minha avaliação. A falha foi corrigida em agosto, mas só divulgada em outubro, 53 dias depois. Além disso, a correção foi inicialmente listada como um simples “bug fix”, sem destaque para a gravidade. Isso levanta questões sobre a transparência da empresa e o compromisso com a segurança dos clientes.

O que posso fazer para me proteger de ataques semelhantes?

Além de manter todos os softwares atualizados, é crucial implementar validações adicionais em seu código, educar sua equipe sobre phishing e adotar uma abordagem de zero confiança. Monitore suas credenciais regularmente e considere usar serviços de monitoramento de identidade digital, como a Kzarka, para ser alertado se seus dados aparecerem em vazamentos.

Não espere que as empresas protejam você. Assuma o controle da sua segurança digital. Visite a Kzarka agora mesmo para verificar se seus dados já foram expostos em vazamentos e monitore sua identidade digital de forma proativa. A prevenção é a melhor defesa.