Pesquisadores de cibersegurança da Wiz revelaram uma nova vulnerabilidade de injeção em workflow do GitHub Actions no repositório público snowflakedb/snowflake-connector-net, da Snowflake. Segundo a empresa, o problema poderia ser explorado por meio de um issue malicioso no GitHub para executar comandos em um workflow que continha credenciais internas do Jira.
A falha estava presente em .github/workflows/jira_issue.yml, que era executado quando um issue público era aberto, e expunha JIRA_BASE_URL, JIRA_USER_EMAIL e JIRA_API_TOKEN na mesma etapa do workflow. A fraqueza ficava restrita à automação de CI/CD do repositório, sem qualquer versão identificada do Snowflake Connector for .NET afetada.
O workflow inseria diretamente no bloco shell run: os valores de título e corpo do issue controlados pelo atacante. Além disso, verificava github.event.pull_request.user.login mesmo quando o evento era um issue, o que significava que a propriedade de pull request mencionada não existia.
O GitHub explica que, “se você tentar referenciar uma propriedade inexistente, ela será avaliada como uma string vazia”. Nesse caso, a comparação com whitesource-for-github-com[bot] não impediu que um issue comum chegasse ao job.
A Wiz afirmou que seu sistema Red Agent explorou a injeção durante testes de segurança autorizados, depois que o primeiro payload gerou um erro de sintaxe no shell e o sistema mudou a abordagem. Segundo a Wiz, os pesquisadores receberam em seguida um retorno fora de banda do runner do GitHub Actions e obtiveram o token da API do Jira usado pelo workflow.
Segundo a Wiz, o token pertencia a [email protected] e permitia acesso de leitura a projetos do Jira ligados a engenharia, conformidade de segurança e acompanhamento de bug bounty em snowflakecomputing.atlassian.net. As permissões subjacentes do Jira, a execução do workflow e os registros de auditoria não são públicos.
A Wiz informou ter reportado o problema à Snowflake por meio do HackerOne em 23 de junho de 2026, sob o relatório #3819931. A Snowflake publicou uma correção no mesmo dia, no pull request #1402, substituindo a expansão direta de expressões do GitHub por variáveis de ambiente passadas ao jq como argumentos.
O workflow vulnerável havia chegado à branch padrão cinco dias antes, em 18 de junho, quando o pull request #1218 foi incorporado. O tratamento corrigido permanece na branch master do repositório.
Em nota reproduzida pela Wiz, a Snowflake disse que “nossa investigação não encontrou evidências de acesso não autorizado”. A Wiz afirmou que o token do Jira foi rotacionado em 24 de junho e que a análise da Snowflake não identificou uso externo não relacionado durante a janela de exposição de cinco dias. Os logs de auditoria da Snowflake não foram tornados públicos.
A Wiz descreveu a falha como resultado de uma mudança feita pelo GitHub Copilot Autofix, embora o histórico subjacente do GitHub não estabeleça o Copilot como autor do código vulnerável em jira_issue.yml. O commit explícito com coautoria do Copilot, 6d0e2fa, alterou jira_close.yml, enquanto a refatoração insegura de jira_issue.yml aparece em outro commit de 25 de agosto de 2025, o 094038e, atribuído pelo GitHub a sfc-gh-hpathak.
Ambas as mudanças acabaram incorporadas ao commit de squash merge 4a1b8ce, de 18 de junho, que lista o Copilot Autofix entre seus coautores. O histórico de commits, portanto, confirma a participação do Copilot no pull request #1218, mas não a autoria das linhas vulneráveis.
O GitHub já havia documentado essa classe de injeção em workflow em julho de 2025, alertando contra a expansão direta de dados não confiáveis de issues dentro de blocos run: e recomendando o uso de variáveis de ambiente intermediárias.
Até 17 de agosto de 2026, não havia sido localizado CVE, pontuação CVSS ou registro no catálogo Known Exploited Vulnerabilities, da CISA, para o problema, e nenhuma atualização de release do connector vinculada a ele havia sido identificada. A interpolação vulnerável não existe mais na branch master, e o material primário disponível não comprova exploração maliciosa em ambiente real nem comprometimento de clientes.
Publicidade
Vibecoding cria 10x mais sistemas, 20x mais vulneráveis. E quem ganha com isso é a galera do hacking ético e pentest. Quer ser pago para invadir sistemas? Então você tem que aprender com a Solyd que são os melhores do Brasil. Saiba mais...