SSRF no Google Cloud Apigee-X pode vazar tokens de conta de serviço (CVE-2026-2264)

A Google Cloud corrigiu uma falha de server-side request forgery no Apigee-X, sua plataforma de gestão de APIs, capaz de vazar tokens de acesso de contas de serviço. A CVE-2026-2264, divulgada em 26 de maio no boletim de segurança gcp-2026-034, recebeu nota 9,2 no CVSS 4.0, com uma ressalva importante embutida no próprio aviso.

A falha e a sua condição de entrada

O problema está na policy SetIntegrationRequest do Apigee. Segundo o registro da Google Cloud, um atacante remoto pode usá-la para executar uma SSRF (CWE-918) e exfiltrar tokens de acesso de contas de serviço, as credenciais que o proxy de API usa para falar com outros serviços do Google Cloud. De posse desses tokens, o atacante herda as permissões da conta de serviço, o que costuma significar acesso a recursos bem além do gateway.

A ressalva está escrita no aviso e não deve ser apagada na pressa: para a exploração funcionar, um administrador precisa primeiro ter estabelecido uma configuração insegura no proxy de API. O vetor CVSS 4.0 reflete isso ao marcar requisitos de ataque presentes (AT:P). Em outras palavras, a falha não dispara sozinha em qualquer instalação padrão; ela depende de uma porta deixada aberta na configuração. Isso não a torna inofensiva, porque configurações inseguras de proxy são comuns onde a pressa de entregar a integração venceu a revisão de segurança, mas ajusta a expectativa: o 9,2 mede o estrago possível, não a facilidade universal.

As versões afetadas do runtime do Apigee-X são anteriores à 1.14.4, à 1.15.2 e à 1.16.1. Por ser um serviço gerenciado, a correção de fundo é aplicada pela própria Google no runtime, o que muda a natureza da resposta do cliente em relação a um produto instalado em casa.

O que o cliente ainda precisa fazer

Serviço gerenciado não quer dizer responsabilidade zero. Mesmo com o runtime corrigido pela Google, cabe ao cliente caçar os proxies que usam a policy SetIntegrationRequest e revisar se algum deles carrega a configuração insegura que abre o flanco. Cabe também avaliar o escopo das contas de serviço ligadas ao Apigee: quanto mais amplo o privilégio dessas contas, maior o prêmio que um token vazado representa. O princípio de menor privilégio, aqui, é a diferença entre um incidente contido e um pivô para o resto do projeto na nuvem. A própria nota de versão dá o mapa da auditoria: runtimes anteriores à 1.14.4, à 1.15.2 e à 1.16.1 carregam o defeito, e confirmar em qual deles cada ambiente roda é o primeiro item da checagem.

O que muda para o Brasil

O Apigee ocupa um lugar específico no mercado brasileiro: é uma das camadas de gestão de API usadas por bancos e fintechs para expor as interfaces reguladas do Open Finance Brasil. É por gateways desse tipo que trafegam consentimentos, dados de conta e iniciações de pagamento entre instituições. Uma SSRF que vaza credenciais de conta de serviço bem nessa camada é sensível por definição, porque o gateway senta exatamente sobre o fluxo de dados que a regulação manda proteger.

A leitura para o CISO de uma instituição financeira brasileira tem duas pontas. A primeira é a boa notícia: por ser gerenciado, o Apigee-X não exige uma corrida de patch no meio da madrugada como exigiria um servidor instalado internamente. A segunda é o trabalho que sobra: auditar a configuração dos proxies que expõem APIs reguladas e confirmar que nenhuma conta de serviço acumulou permissões além do necessário. A configuração insegura que a falha exige não nasce de má-fé; nasce de proxies montados às pressas para cumprir prazo regulatório, e é aí que a revisão precisa entrar.

A lição que atravessa o caso é menos sobre esta CVE e mais sobre o ponto cego do modelo gerenciado. Mover a infraestrutura para um serviço operado pelo fornecedor transfere o patch, não a responsabilidade pela configuração. A parte que continua nas mãos do cliente, a de como o proxy foi montado e quanto privilégio a conta de serviço carrega, é justamente a que esta falha cobra.