Falha no GitHub Actions da Snowflake expôs token interno do Jira a injeção de comandos
Pesquisadores da Wiz identificaram uma vulnerabilidade de injeção de comandos em um workflow do GitHub Actions no repositório público snowflakedb/snowflake-connector-net, da Snowflake. Durante testes autorizados, a falha permitiu executar comandos a partir de uma issue especialmente preparada e obter um token de API interno do Jira.
O problema estava no arquivo ".github/workflows/jira_issue.yml", executado automaticamente quando uma issue pública era aberta no repositório. O mesmo workflow tinha acesso às variáveis JIRA_BASE_URL, JIRA_USER_EMAIL e JIRA_API_TOKEN.
Segundo a análise, o título e o conteúdo das issues, controlados por usuários externos, eram inseridos diretamente em um bloco shell "run:". Isso criava uma condição de workflow injection, na qual dados não confiáveis podiam ser interpretados como comandos pelo runner do GitHub Actions.
O workflow também verificava a propriedade "github.event.pull_request.user.login", embora o evento processado fosse uma issue. Como essa propriedade de pull request não existia naquele contexto, o GitHub Actions a avaliava como uma string vazia. Com isso, a comparação utilizada para bloquear determinados eventos não impedia que uma issue comum chegasse à etapa vulnerável.
Durante testes de segurança autorizados, o sistema Red Agent, da Wiz, tentou explorar a injeção. Depois que um primeiro payload provocou um erro de sintaxe no shell, o sistema alterou a abordagem e conseguiu receber uma conexão externa originada do runner do GitHub Actions.
Os pesquisadores afirmam que, a partir da exploração, conseguiram obter o token da API do Jira utilizado pelo workflow. De acordo com a Wiz, a credencial pertencia à conta qa@snowflake.net e fornecia acesso de leitura a projetos internos relacionados a engenharia, conformidade de segurança e acompanhamento de programas de bug bounty no ambiente Jira da Snowflake.
As permissões completas da conta, os registros de execução do workflow e os logs de auditoria do Jira não foram divulgados publicamente.
A Wiz informou a vulnerabilidade à Snowflake por meio do HackerOne em 23 de junho de 2026, no relatório #3819931. A empresa implementou uma correção no mesmo dia por meio do pull request #1402.
A mudança eliminou a expansão direta das expressões provenientes do GitHub dentro do shell. Os dados passaram a ser armazenados em variáveis de ambiente e fornecidos ao "jq" como argumentos, reduzindo o risco de que conteúdo controlado por usuários seja interpretado como comandos.
O workflow vulnerável havia chegado à branch padrão cinco dias antes, em 18 de junho, após a integração do pull request #1218. O tratamento corrigido permanece na branch master do repositório.
Segundo declaração da Snowflake reproduzida pela Wiz, a investigação da empresa não encontrou evidências de acesso não autorizado. O token do Jira foi rotacionado em 24 de junho, e a análise também não teria identificado uso externo não relacionado da credencial durante os cinco dias em que ela ficou exposta. Os logs de auditoria utilizados nessa investigação, porém, não foram publicados.
Papel do GitHub Copilot não está confirmado
A Wiz descreveu a vulnerabilidade como resultado de uma alteração do GitHub Copilot Autofix, mas o histórico disponível no GitHub não confirma que o Copilot tenha sido responsável especificamente pelas linhas vulneráveis do arquivo "jira_issue.yml".
O commit explicitamente identificado como coautorado pelo Copilot, 6d0e2fa, modificou o arquivo "jira_close.yml". Já a alteração insegura em "jira_issue.yml" aparece em outro commit, 094038e, de 25 de agosto de 2025, atribuído pelo GitHub a sfc-gh-hpathak.
Posteriormente, as duas mudanças foram incorporadas ao squash merge 4a1b8ce, de 18 de junho, que lista o Copilot Autofix entre seus coautores. O histórico confirma, portanto, a participação do Copilot no pull request #1218, mas não permite atribuir a ele a autoria do código vulnerável.
O GitHub já havia documentado esse tipo de workflow injection em julho de 2025, recomendando que dados não confiáveis provenientes de issues não fossem expandidos diretamente em blocos "run:" e que variáveis de ambiente intermediárias fossem utilizadas.
Até 17 de agosto de 2026, não havia CVE, pontuação CVSS ou registro no catálogo Known Exploited Vulnerabilities (KEV) da CISA associado ao problema. Também não foi identificada nenhuma versão do Snowflake Connector for .NET afetada, já que a vulnerabilidade estava restrita à automação de CI/CD do repositório.
A interpolação vulnerável já foi removida da branch master. As informações disponíveis também não indicam exploração maliciosa da falha em ambiente real nem comprometimento de clientes da Snowflake.
