Falha no Snowflake permitia obter token interno do Jira por meio do GitHub Actions
Uma vulnerabilidade em um fluxo de automação da Snowflake expôs temporariamente uma credencial interna usada para integração com o Jira. O problema estava no repositório público `snowflakedb/snowflake-connector-net` e poderia ser explorado por qualquer pessoa capaz de abrir uma issue especialmente preparada.
A falha combinava dois erros de segurança. Primeiro, o workflow do GitHub Actions inseria diretamente o título e o texto das issues em comandos executados no shell, sem aplicar validação ou escape adequado. Esse comportamento criava uma possibilidade de injeção de comandos, permitindo que conteúdo controlado pelo usuário fosse interpretado pelo sistema como instrução executável.
O segundo problema estava na própria tentativa de restringir o uso do workflow. O mecanismo de proteção verificava uma propriedade associada a pull requests, embora o fluxo fosse acionado por eventos de issues. Como esse campo não existia nesse tipo de evento, a checagem não funcionava como esperado e usuários sem privilégios conseguiam alcançar o runner utilizado pela automação.
Durante uma avaliação autorizada, um agente autônomo de segurança demonstrou que a combinação dessas falhas podia ser explorada na prática. Após executar comandos no ambiente do runner, o agente conseguiu localizar e extrair um token de API do Jira armazenado nas variáveis do pipeline.
A credencial não permitia modificar dados, mas possuía autorização de leitura em projetos internos. Entre as áreas potencialmente acessíveis estavam iniciativas de engenharia, atividades de conformidade de segurança e programas de recompensa por vulnerabilidades. Mesmo com permissões limitadas, esse tipo de acesso poderia fornecer informações valiosas para planejar novas tentativas de invasão, identificar equipes responsáveis ou descobrir detalhes sobre sistemas corporativos.
Segundo as informações do caso, a vulnerabilidade permaneceu disponível entre 18 e 23 de junho de 2026. A Snowflake corrigiu o workflow no mesmo dia em que recebeu o alerta e substituiu o token potencialmente exposto no dia seguinte. A troca da credencial foi uma medida importante, pois corrigir o código não invalida automaticamente segredos que possam ter sido visualizados durante a exploração.
O código afetado fazia parte de um pull request que contou com participação do GitHub Copilot. No entanto, o histórico público analisado não permite afirmar que a ferramenta de inteligência artificial tenha criado especificamente as linhas vulneráveis. A presença da IA no processo de desenvolvimento, portanto, não constitui prova de que ela tenha sido a origem direta do erro.
Por que essa vulnerabilidade era perigosa
Workflows do GitHub Actions frequentemente executam tarefas com acesso a variáveis de ambiente, tokens, artefatos e outros recursos internos. Quando um fluxo é acionado por dados fornecidos por usuários externos, como issues ou comentários, essas informações devem ser tratadas como não confiáveis.
Inserir texto de uma issue em um comando shell é particularmente arriscado. Um título aparentemente comum pode conter operadores, redirecionamentos ou instruções adicionais capazes de alterar a lógica original do comando. Se o runner também tiver acesso a segredos, a exploração pode evoluir de uma simples execução arbitrária para o roubo de credenciais.
Outro ponto crítico foi a validação baseada no tipo errado de evento. Regras de autorização precisam considerar o contexto exato em que o workflow é executado. Campos disponíveis em eventos de pull request não necessariamente existem em eventos de issue. Quando uma verificação depende de um valor ausente, o sistema pode interpretar a condição de maneira permissiva e liberar ações que deveriam ser bloqueadas.
Como evitar problemas semelhantes
A prática mais segura é nunca construir comandos shell diretamente a partir de títulos, descrições, comentários ou nomes de branches controlados por usuários. Esses valores devem ser tratados como dados, não como partes da instrução. Quando possível, os parâmetros devem ser passados por mecanismos seguros da própria linguagem ou por arquivos temporários devidamente protegidos.
Também é recomendável separar workflows destinados a colaboradores internos daqueles que processam contribuições públicas. Eventos como `pull_request_target`, por exemplo, exigem atenção especial porque podem combinar código não confiável com permissões do repositório principal. A concessão de segredos deve ser mínima e limitada ao estágio estritamente necessário.
Tokens usados em integrações precisam ter escopo reduzido, validade curta e permissões somente de leitura quando não houver necessidade de escrita. Além disso, devem ser armazenados no gerenciador de segredos da plataforma, monitorados e revogados imediatamente diante de qualquer suspeita de exposição.
A revisão de segurança não deve se limitar ao código da aplicação. Arquivos de configuração, pipelines de CI/CD e scripts de automação também precisam passar por análise. Ferramentas automatizadas podem ajudar a identificar comandos perigosos, uso indevido de variáveis e exposição de credenciais, mas os resultados devem ser verificados por profissionais.
Por fim, organizações devem manter registros detalhados das execuções dos workflows e criar alertas para comportamentos incomuns, como acesso inesperado a variáveis protegidas, execução de comandos fora do padrão ou consultas atípicas a sistemas internos. A combinação de validação correta, menor privilégio, rotação de segredos e monitoramento reduz significativamente o impacto de falhas desse tipo.