O Google Cloud VRP ganhou uma nova categoria de recompensa que pode pagar até US$ 250 mil a pesquisadores de segurança capazes de identificar falhas estruturais graves na infraestrutura de nuvem do Google. A iniciativa, chamada Root-in-Cloud, foi criada para incentivar a descoberta de vulnerabilidades que ultrapassem as barreiras de isolamento entre clientes e permitam obter controle administrativo sobre organizações ou projetos sem qualquer acesso prévio.
A mudança representa uma aposta em pesquisas de segurança mais profundas, especialmente aquelas que investigam problemas arquiteturais em vez de vulnerabilidades convencionais em aplicações. Entre os cenários contemplados estão a quebra do isolamento multitenant, a obtenção de privilégios administrativos arbitrários no Identity and Access Management (IAM) e a execução remota de código na infraestrutura de produção baseada no Borg, sistema utilizado pelo Google para administrar cargas de trabalho em larga escala.
A iniciativa também chega em um momento delicado para o mercado de bug bounty. Enquanto ferramentas de inteligência artificial facilitam a identificação de possíveis vulnerabilidades, relatórios automatizados de baixa qualidade aumentam o trabalho das equipes responsáveis pela triagem. Nesse contexto, o Google procura valorizar descobertas comprováveis, com impacto real e demonstrações técnicas que não coloquem os dados ou os serviços dos clientes em risco.
O que são falhas de Root-in-Cloud e por que elas valem tanto?
O termo Root-in-Cloud representa uma classe de vulnerabilidades capazes de comprometer os limites fundamentais de segurança da infraestrutura do Google Cloud. Não se trata simplesmente de conseguir acesso administrativo a uma máquina virtual ou explorar uma configuração incorreta em um serviço isolado.
O objetivo é demonstrar que uma falha na arquitetura da plataforma permite ultrapassar as barreiras que deveriam separar organizações, projetos e clientes diferentes. Em um ambiente multitenant, essa separação é essencial para impedir que uma empresa consiga acessar recursos pertencentes a outra.
Uma vulnerabilidade dessa natureza pode comprometer a confiança em toda a infraestrutura compartilhada. Por isso, o Google estabeleceu uma recompensa especial de US$ 250 mil, direcionada a descobertas com impacto arquitetural excepcional.
Quebra de isolamento de tenants e sequestro de IAM
Um dos principais cenários contemplados pelo novo nível de recompensa envolve a quebra do isolamento entre tenants. Na prática, isso significa encontrar uma maneira de ultrapassar os mecanismos que impedem um usuário de acessar recursos de outras organizações ou projetos.
O segundo elemento fundamental é o comprometimento do Identity and Access Management (IAM), sistema responsável por controlar identidades, funções e permissões dentro do Google Cloud.
Para alcançar a recompensa máxima, o pesquisador precisa demonstrar a capacidade de obter controle administrativo equivalente à função roles/owner, ou seja, privilégios que permitam administrar integralmente uma organização ou projeto arbitrário.
Esse nível de acesso é particularmente perigoso porque permite modificar políticas de permissões, administrar contas de serviço e controlar recursos associados ao projeto comprometido.
O requisito mais importante é que essa capacidade seja obtida sem acesso prévio ao ambiente da vítima. Uma exploração que dependa de credenciais roubadas, privilégios existentes ou preparação especial do projeto não atende aos critérios da nova categoria.
Isso diferencia o Root-in-Cloud de uma escalada convencional de privilégios. O pesquisador precisa comprovar que uma falha estrutural permite atravessar uma fronteira de confiança que deveria permanecer protegida mesmo diante de um usuário externo sem privilégios.
RCE no Borg e impacto na infraestrutura de produção
Outro cenário relevante envolve a possibilidade de Remote Code Execution (RCE) na infraestrutura de produção do Google, especialmente no Borg.
O Borg é o sistema interno de gerenciamento de clusters utilizado pelo Google para executar e administrar grandes volumes de aplicações e serviços distribuídos. Ele coordena cargas de trabalho, recursos computacionais e tarefas em uma infraestrutura de escala global.
Uma execução arbitrária de código nesse ambiente representa um risco muito diferente de uma falha limitada a uma aplicação individual. Dependendo do contexto de execução e das permissões disponíveis, uma vulnerabilidade pode abrir caminho para comprometer componentes compartilhados ou ultrapassar fronteiras entre ambientes.
O Google esclarece que relatórios válidos demonstrando RCE na infraestrutura Borg ou alcançando o chamado root-in-prod serão avaliados automaticamente pelo painel do Cloud VRP para verificar sua elegibilidade à categoria Root-in-Cloud.
Isso não significa que qualquer execução de código no Borg garante automaticamente US$ 250 mil. A equipe avaliará o ponto inicial de entrada, o contexto de execução e a superfície de ataque para determinar se existe potencial de comprometimento administrativo de projetos ou organizações arbitrários.
Regras do Google Cloud VRP e o método seguro de validação
Uma recompensa elevada exige critérios de exploração igualmente rigorosos. Afinal, testar uma vulnerabilidade em uma infraestrutura utilizada por empresas, instituições financeiras e outros clientes não pode significar colocar dados de terceiros em risco.
O Google estabeleceu limites explícitos para impedir que pesquisadores ultrapassem o necessário para demonstrar a existência de uma falha.
Entre as principais restrições estão:
- Sem engenharia social: a exploração não pode depender de convencer funcionários ou clientes a executar ações.
- Sem credenciais comprometidas: credenciais vazadas, roubadas ou obtidas por phishing não podem constituir o caminho de ataque.
- Sem acesso prévio: o pesquisador não pode depender de uma posição privilegiada no projeto ou organização da vítima.
- Sem movimentação lateral: não é permitido utilizar o primeiro acesso como ponto de partida para explorar outros componentes da infraestrutura.
- Sem extração de credenciais de produção: obter segredos ou credenciais reais da infraestrutura está fora dos limites autorizados.
- Sem acesso indevido a dados de clientes: os testes não devem comprometer informações ou recursos pertencentes a terceiros.
Uma das medidas mais interessantes é o mecanismo chamado Proof-of-root, desenvolvido para permitir uma demonstração técnica sem comprometer projetos reais.
Prova criptográfica sem acessar ambientes de clientes
Tradicionalmente, demonstrar uma falha de controle administrativo em uma plataforma de nuvem poderia exigir a exploração de um projeto real. Isso criaria um problema importante: provar o impacto da vulnerabilidade poderia significar realizar exatamente o tipo de ação que o programa pretende impedir.
Para evitar esse cenário, o Google criou um mecanismo determinístico de prova de raiz, baseado em uma conta de serviço especificamente designada para essa finalidade.
Em vez de tentar assumir o controle de uma organização pertencente a um cliente, o pesquisador demonstra criptograficamente que conseguiu obter acesso não autorizado à identidade de teste disponibilizada pelo programa.
Essa abordagem permite validar a existência da falha de maneira controlada e reproduzível. A comprovação utiliza uma identidade específica, evitando que a pesquisa dependa da manipulação de permissões ou da exposição de informações reais de terceiros.
O mecanismo também reduz a ambiguidade durante a análise dos relatórios. A equipe de segurança pode verificar se o pesquisador realmente ultrapassou a fronteira de autorização, em vez de depender apenas de capturas de tela ou descrições teóricas de uma possível exploração.
No caso de uma execução de código no Borg, entretanto, existe uma regra ainda mais importante: o pesquisador deve interromper imediatamente qualquer sondagem assim que conseguir executar código na infraestrutura.
Continuar a exploração, tentar ampliar privilégios ou buscar credenciais de produção pode resultar na desqualificação, mesmo que a descoberta inicial seja legítima.
A mensagem do Google é clara: demonstrar o impacto é necessário, mas preservar a segurança dos clientes tem prioridade sobre qualquer recompensa.
O panorama dos programas de recompensa e o desafio da IA
A expansão do Google Cloud VRP também precisa ser analisada dentro do histórico dos programas de recompensa da empresa.
Desde 2010, o Google distribuiu aproximadamente US$ 81,6 milhões a pesquisadores que identificaram vulnerabilidades em seus produtos e serviços. Em 2025, os pagamentos ultrapassaram US$ 17 milhões, estabelecendo um recorde histórico, com 747 pesquisadores remunerados.
Esses números mostram que a empresa continua investindo fortemente na comunidade independente de segurança. Entretanto, o crescimento da inteligência artificial introduziu um problema operacional: o aumento expressivo de relatórios que parecem tecnicamente convincentes, mas não apresentam vulnerabilidades reais ou impacto demonstrável.
O problema ficou especialmente evidente no Open Source Software Vulnerability Reward Program (OSS VRP).
Em 2026, o Google anunciou mudanças nas regras do programa após observar uma grande quantidade de relatórios produzidos com auxílio de inteligência artificial. Entre os problemas identificados estavam informações incorretas, cenários de exploração inventados e falhas de programação sem impacto efetivo na segurança.
Posteriormente, a empresa também suspendeu temporariamente o recebimento de novas submissões de determinadas vulnerabilidades de projetos de código aberto, a partir de outubro de 2026, diante do volume de relatórios automatizados inválidos.
A resposta envolveu elevar as exigências de comprovação técnica, incluindo evidências mais robustas, como reproduções verificáveis e correções incorporadas aos projetos em determinadas categorias.
Existe uma diferença importante entre utilizar IA como ferramenta de pesquisa e simplesmente encaminhar resultados automatizados sem validação. A primeira abordagem pode ampliar a capacidade de investigação; a segunda transfere para as equipes de segurança o trabalho de separar hipóteses de descobertas legítimas.
O novo nível de recompensa do Cloud VRP representa uma resposta interessante a esse cenário. Em vez de simplesmente aumentar o volume de submissões, o Google pretende estimular pesquisas que exijam compreensão profunda de arquiteturas distribuídas, relações de confiança e mecanismos de autorização.
Isso não significa abandonar a automação. Pelo contrário, a própria liderança do programa reconhece o potencial da combinação entre criatividade humana e ferramentas de pesquisa baseadas em agentes de IA.
A diferença está na qualidade da evidência e na capacidade de demonstrar consequências concretas para a segurança da infraestrutura.
Impacto na segurança em nuvem e próximos passos
A criação da recompensa de US$ 250 mil para Root-in-Cloud sinaliza uma mudança importante na forma como grandes provedores de nuvem valorizam pesquisas de segurança.
Durante muito tempo, programas de bug bounty concentraram grande parte da atenção em vulnerabilidades de aplicações, interfaces, APIs e componentes individuais. Embora essas descobertas continuem relevantes, falhas arquiteturais podem representar riscos muito maiores, especialmente quando afetam os mecanismos responsáveis pelo isolamento de milhares de clientes.
Para administradores de sistemas, equipes de DevOps e profissionais de segurança corporativa, a iniciativa reforça uma questão fundamental: a segurança de um ambiente de nuvem não depende apenas da proteção das aplicações hospedadas, mas também da integridade da infraestrutura compartilhada que sustenta esses serviços.
O investimento em pesquisas independentes também demonstra que mesmo empresas com equipes internas altamente especializadas precisam de avaliações externas para identificar problemas que podem passar despercebidos durante o desenvolvimento e a operação cotidiana.
Outro ponto importante é a valorização da divulgação responsável. Uma descoberta de alto impacto precisa ser acompanhada de evidências reproduzíveis, comunicação adequada e respeito aos limites estabelecidos pelo programa.
O desafio será equilibrar recompensas elevadas, automação de pesquisas e capacidade de análise das equipes responsáveis pela triagem. Se bem executado, esse modelo pode incentivar descobertas realmente relevantes sem transformar os programas de recompensa em canais sobrecarregados por relatórios gerados automaticamente.
