SAP Cloud SDK: a correção precisa sobreviver à refatoração da autenticação

A SAP divulgou a CVE-2026-89111, com CVSS 10,0, no Cloud SDK for Python.[6] Em aplicações multitenant que deixam o cliente controlar o subdomínio passado ao SDK, uma entrada malformada pode redirecionar a requisição de token OAuth2 e enviar client ID e client secret a um destino do atacante.[6] A consequência posterior depende das permissões dessas credenciais.[6] O problema não termina em escolher uma versão numericamente maior.

O que muda para quem desenvolve

A correção oficial é a 0.45.2, lançada em 21 de agosto de 2026, com validação do subdomínio antes da requisição.[6] Entretanto, o The Hacker News encontrou seis releases entre 0.53.0 e 0.55.0 sem essa checagem no módulo Destination.[6] A migração para um caminho compartilhado de obtenção de tokens não preservou a proteção, reincorporada na 0.55.1.[6]

Minha leitura é que a regra de segurança pertencia ao contrato de autenticação, mas não foi preservada no novo caminho de execução. Uma função auxiliar pode parecer equivalente e ainda mudar a fronteira entre uma entrada do cliente e o servidor autorizado a receber um segredo.

Esse é o tipo de requisito que deve ser testado pelo efeito: para um tenant inválido, nenhuma requisição com credenciais deve sair. Verificar apenas o retorno de um validador deixa aberta a possibilidade de outra chamada contornar a função.

Como aplicar

Inventarie a versão instalada e os módulos realmente utilizados. A matéria informa que a linha 0.36 continuava sem proteção mesmo em releases publicados após a correção de agosto.[6] Evite regras de conformidade baseadas somente na data ou em uma comparação genérica de versões.

Em um ambiente isolado, substitua o transporte HTTP por um mock que registre tentativas de saída. Use apenas credenciais fictícias. Teste um tenant registrado, um desconhecido e entradas que deveriam ser rejeitadas por conter delimitadores de URL. O aceite deve distinguir rejeição antes do envio de erro recebido depois que a requisição já saiu.

Repita o teste nos módulos de integração usados pelo produto. Ao refatorar a autenticação, mantenha essa suíte junto do contrato compartilhado e confira se cada consumidor continua coberto. Uma proteção centralizada só ajuda quando todas as rotas passam por ela.

Como mitigação para quem não pode atualizar, a SAP sugere validar o subdomínio contra a lista de tenants registrados.[6] Proponha também revisar o histórico de destinos de autenticação e avaliar rotação quando houver indício de exposição, sem apresentar isso como orientação explícita do aviso.

Cuidados e limites

Há divergência documental: em 13 de outubro, o aviso oficial não listava versões posteriores à 0.45.2 como afetadas nem esclarecia a classificação formal da regressão na mesma CVE.[6] A observação do código e dos testes pela reportagem deve permanecer atribuída a ela.

O aviso não relata ataques conhecidos.[6] Não transforme gravidade máxima em comprometimento confirmado. O ponto verificável é preservar a restrição de destino antes de qualquer envio de segredo, inclusive depois de reorganizar o código.

Fonte

[6] Fonte: The Hacker News