Pickle in the Middle uma vulnerabilidade de Vertex AI que permite executar código e roubar modelos

Uma falha no SDK do Google Cloud Vertex AI permitiu que um atacante sem credenciais ou acesso prévio ao projeto da vítima sequestrasse a carga de um modelo e executasse código na infraestrutura de serving do Google. Palo Alto Networks Unit 42 bautizou a técnica como "Pickle in the Middle" e notificou o problema do Google; o fabricante já reduziu o SDK, mas a incidência deixa lições importantes sobre riscos de design e práticas inseguras em pipelines de machine learning.

A raiz técnica foi simples e perigosa: quando o SDK precisava de um bucket temporário para subir artefatos de modelo e o usuário não especificava um, gerava um nome previsível a partir do ID do projeto e da região — por exemploproject-vertex-staging-region— e verificava apenas se existia, não se o bucket pertencia ao projeto do usuário. Como os nomes de buckets são globalmente únicos, um atacante com seu próprio projeto poderia criar primeiro esse bucket e esperar o aumento da vítima. O atacante então substituiva o conteúdo subido por um artefato malicioso. Uma vez que muitos modelos Python se serializam com pickle ou joblib –formatos que executam código ao deserializar –, quando Vertex AI carregava esse modelo o payload do atacante se executava dentro do recipiente de serving.

A exploração dependia de uma janela de tempo (TOCTOU): Umit 42 mediu um intervalo de aproximadamente 2, 5 segundos entre a subida e a leitura por Vertex AI; em seu teste de conceito um Cloud Function substituiu o objeto em 1,4 segundos e o payload roubou um token OAuth desde o servidor de metadados do recipiente, enviando-o para o atacante. Esse token, no ambiente de teste, tinha permissões mais amplas que a simples instância comprometida: permitiu acessar outros artefatos no tenant gerido pelo Google, incluindo modelos completos, metadados do BigQuery, listas de acesso, logs e rotas internas de imagens de contêiner. Ou seja, a exploração poderia resultar em execução remota de código, roubo de modelos e movimento lateral dentro do tenant.

O vetor funcionou apenas se concorreriam duas condições comuns: que o bucket por defeito de staging não existisse na região (setuação habitual em projetos novos) e que o desenvolvedor não tivesse estabelecido explicitamente o parâmetrostaging_bucket. Unit 42 reportou a vulnerabilidade em 5 de março de 2026; o Google lançou um acordo inicial (aleatorizando o nome com uuid4) e completou a correção adicionando uma verificação de propriedade do bucket em Model.upload () na versão 1.148. 0 do pacote.

As implicações para equipes de ML e segurança são amplas: além da perda de propriedade intelectual (modelos roubados ou envenenados), a técnica destaca como decisões de design em clientes e defaults inseguros podem se tornar vetores de escalada sem phishing ou exploits complexos. Também sublinha o risco de formatos de serialização inseguros em ambientes multitenant e a necessidade de políticas que evitem a criação de recursos previsíveis que possam ser aproveitados por um concorrente ou um atacante externo.

Acções imediatas recomendadas: atualize o SDK para a versão alterada com o comando pip (por exemplopip install -- upgrade google-cloud-aiplatform>=1.148.0) e, muito importante, defina sempre explicitamente staging_bucket Como uma localização do Cloud Storage que você controle. Verifique a versão doGoogle-cloud-aiplatformonde quer que seja executado: notebooks, CI/CD, pipelines de treinamento e ambientes de teste, não apenas em produção. Se suspeitar que pode ter exposição antes do adesivo, considere rotar credenciais e tokens de serviço afetados e rever o histórico de objetos dos buckets públicos ou compartilhados.

Para além do adesivo, verifique as suas práticas de serialização: se possível, evite enviar modelos em formatos que executem o código em carga como pickle/joblib; prefira formatos concebidos para a instalação segura (SavedModel, ONNX ou exportações que não executem o código ao carregar). No plano de controle de acesso, limite as permissões associadas a agentes e contas de serviço, use Workload Identity e aplique políticas organizacionais que impeçam a criação de recursos com nomes previsíveis ou que obriguem à vinculação de buckets a projetos concretos.

Para equipes de resposta e risco, audite logs de Cloud Storage e Vertex AI por operações invulgares nas janelas de carga de modelos, e verifique acessos à metadata server e tokens emitidos por serviços gerenciados. Este incidente volta a colocar sobre a mesa a necessidade de tratar a cadeia de fornecimento de ML como um vetor de ameaça: desde o código do cliente até os artefatos que se desdobram em produção.

Leia a análise técnica e a notificação da pesquisadora original na web de Unit 42 para detalhes do PoC e tempos de exploração: Unit 42. Verifique as notas de lançamento e versões do SDK no repositório oficial para confirmar que o seu ambiente está atualizado: python-aiplatform releases e a página do pacote no PyPI: Google-cloud-aiplatform on PyPI. Actúe hoje: adesivo e fixação do bucket de staging remove a janela de ataque conhecida; complementando-o com controles de acesso e práticas de serialização seguras reduz significativamente o risco.