Python: pacote com 1,1 milhão de downloads é infectdo por falha GitHub

No último dia 24 de abril, a comunidade de engenharia de dados↳Engenharia de dados43 conteúdosResolvendo desafios de Big Data com Ciência de Dados na UberData · abr 2019Análise de dados com Python e tabelas dinâmicas com PandasData · mai 2019Ferramentas para análise de dados são cada vez mais fundamentais para auxiliar pessoas desenvolvedorasData · jun 2024Ver tudo em Data → foi surpreendida por um incidente que reacende um debate antigo. Para desenvolvedores Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) →, a recomendação imediata é clara. Primeiramente, audite todas as versões do elementary-data instaladas em seu ambiente. Afinal, até onde podemos confiar em pipelines automatizados de CI/CD? Uma versão maliciosa do pacote elementary-data, amplamente utilizado no ecossistema dbt, foi publicada no PyPI e no GitHub Container Registry. Além disso, o ataque não comprometeu nenhuma credencial de mantenedor. Em vez disso, explorou uma vulnerabilidade conceitual no próprio workflow de automação do projeto.

Consequentemente, todos os ambientes que instalaram a versão envenenada tiveram credenciais de AWS, GCP e Azure expostas. Ademais, chaves SSH, carteiras de criptomoedas e segredos de infraestrutura também foram coletados pelo atacante.

O alvo: uma ferramenta crítica para observabilidade de dados (Python)

Antes de mais nada, é importante entender por que esse incidente é especialmente grave. O elementary-data é uma ferramenta open-source de observabilidade voltada ao ecossistema dbt. Portanto, engenheiros de dados a utilizam para monitorar pipelines em produção.

Atualmente, o pacote acumula mais de 1,1 milhão de downloads mensais no PyPI. Além disso, sua presença em ambientes corporativos é significativa. Dessa forma, o impacto potencial do ataque alcança desde startups até grandes empresas com infraestrutura de dados crítica.

A porta de entrada: um workflow vulnerável a injeção

Em primeiro lugar, vale destacar onde tudo começou. O projeto mantinha um workflow chamado update_pylon_issue.yml no GitHub Actions. Basicamente, ele processava comentários de pull requests automaticamente.

Contudo, esse workflow continha um erro clássico de segurança. Ou seja, interpolava o conteúdo do comentário diretamente em um comando de shell, sem qualquer sanitização. Por consequência, qualquer string passada como comentário poderia ser interpretada como código executável.

Para fins de comparação, é como se um formulário de contato executasse cada caractere digitado pelo usuário como se fosse um comando do sistema operacional. Em outras palavras, trata-se da definição manual de uma vulnerabilidade de injeção.

A execução: um atacante recém-criado e um comentário aparentemente inofensivo

Posteriormente, o atacante criou uma conta no GitHub com apenas dois dias de existência. Em seguida, postou um comentário em uma pull request aberta. Aparentemente, o conteúdo era apenas texto. Entretanto, embutido nele havia código malicioso.

Quando o workflow leu o comentário, executou o código do atacante dentro da infraestrutura do próprio GitHub. Assim, o invasor obteve acesso ao GITHUB_TOKEN, a chave temporária que o GitHub fornece automaticamente para que automações interajam com o repositório.

Do GITHUB_TOKEN à publicação no PyPI

Com o token em mãos, o atacante seguiu uma cadeia bem orquestrada de ações. Inicialmente, criou um commit contendo o payload malicioso. Em seguida, aplicou a esse commit a tag v0.23.3. Por fim, acionou o pipeline legítimo de publicação do projeto.

Curiosamente, o commit aparece com o selo verde de “Verificado” no GitHub. A assinatura, na verdade, é válida. Porém, foi feita com as credenciais do workflow e não com as do mantenedor. Infelizmente, o processo de verificação do GitHub não distingue esse caso.

Adicionalmente, o nome do commit foi copiado de uma PR legítima anterior: release/v0.23.2 (#2188). Dessa maneira, o atacante reduziu drasticamente as chances de levantar suspeitas durante uma revisão superficial.

Em seguida, o pipeline oficial fez exatamente o que foi projetado para fazer. Em outras palavras, construiu o pacote a partir do código marcado com a tag v0.23.3. Logo depois, publicou o wheel e a source distribution no PyPI utilizando as credenciais armazenadas como secrets do repositório.

A imagem Docker também foi contaminada

Paralelamente à publicação no PyPI, o mesmo workflow possuía um job para construir e publicar a imagem Docker do projeto. Por isso, ambos os jobs rodaram juntos contra o commit malicioso. Como resultado, uma imagem multi-arquitetura foi publicada no GitHub Container Registry com as tags 0.23.3 e latest.

A tag latest, especificamente, representa o ponto mais crítico do ataque. Muitos times fixam versões de pacotes Python em arquivos requirements.txt ou em lockfiles. Em contrapartida, usam latest para imagens de container. Às vezes, simplesmente não especificam nenhuma tag, o que tem o mesmo efeito prático.

Portanto, qualquer Dockerfile com uma linha FROM ghcr.io/elementary-data/elementary sem tag fixada puxou a imagem comprometida automaticamente. Essa exposição se manteve ativa desde o dia 24 de abril.

O que esse incidente nos ensina sobre segurança em projetos Python

Em primeiro lugar, este caso prova que comprometer credenciais de mantenedores não é mais o único caminho viável. Hoje, atacantes miram a infraestrutura de automação que cerca o projeto. Ou seja, o supply chain↳Leia tambémO impacto da inteligência artificial no crescimento do Supply ChainMarketing Tech · jun 2024 attack evoluiu.

Adicionalmente, há lições práticas que todo time de engenharia precisa internalizar agora mesmo:

Nunca interpole input externo em comandos de shell dentro de workflows. Em vez disso, use variáveis de ambiente com aspas adequadas ou parâmetros estruturados. Afinal, comentários de PRs, títulos de issues e nomes de branches são todos vetores potenciais de injeção.

Restrinja permissões do GITHUB_TOKEN ao mínimo necessário. Por padrão, o token recebe permissões amplas demais. Contudo, é possível configurar permissions: em cada workflow. Dessa forma, mesmo que um atacante consiga executar código, o estrago será limitado.

Fixe versões de imagens Docker explicitamente. Em outras palavras, evite latest em ambientes de produção. Sempre que possível, utilize digests SHA imutáveis no lugar de tags mutáveis.

Audite workflows acionados por eventos externos. Além disso, eventos como issue_comment, pull_request_target e workflow_run exigem cuidado redobrado. Nesses casos, atacantes não autenticados podem disparar a execução.

Considerações finais sobre a segurança no ecossistema Python

Definitivamente, este ataque não é um caso isolado. Pelo contrário, faz parte de uma tendência crescente de comprometimentos via supply chain. Por outro lado, a boa notícia é que a maioria dos vetores explorados aqui é prevenível com revisões cuidadosas de workflows.

Para desenvolvedores Python, a recomendação imediata é clara. Primeiramente, audite todas as versões do elementary-data instaladas em seu ambiente. Em seguida, verifique imagens Docker baseadas no GitHub Container Registry do projeto. Por fim, rotacione qualquer credencial que possa ter sido exposta entre 24 de abril e a data da remoção do pacote malicioso.

Acima de tudo, este incidente reforça uma verdade desconfortável. Pipelines de CI/CD não são apenas ferramentas de produtividade. Em última análise, são também superfícies de ataque que merecem o mesmo nível de escrutínio que aplicamos ao código de produção.

Siga nosso perfil no Instagram!