CodeQL 2.26.3 refina análise de segurança no GitHub Actions e quebra query de self-hosted runner

O CodeQL 2.26.3, anunciado no changelog do GitHub, mira em dois territórios que viraram alvo preferencial de ataque nos últimos anos: pipelines de CI/CD↳CI/CD23 conteúdosCI/CD Mobile: o caos invisível que separa times comuns de times de alta performanceDev (Back & Front) · abr 2026Lambda: implementando com GitLab CI/CD e Terraform para Integração SFTP, S3 e Databricks em GoDev (Back & Front) · nov 2023Publicando sua aplicação Web Python no WebApp do Azure e configurando o CI/CD da sua aplicaçãoDevSecOps · abr 2019Ver tudo em DevSecOps → no GitHub Actions e código JavaScript↳JavaScript116 conteúdosJavaScript em 2020: O que esperarDev (Back & Front) · jan 2020Campos públicos e privados em classes JavaScript – O que vem por aí no ESNextDev (Back & Front) · abr 201929 anos de JavaScript!Dev (Back & Front) · jan 2025Ver tudo em Dev (Back & Front) →/TypeScript rodando no navegador e no servidor. Para quem não conhece, o CodeQL é o motor de análise estática por trás do GitHub code scanning, aquele que trata seu código como um banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → e roda queries pra encontrar caminhos de dados que terminam em vulnerabilidade (SQL injection, XSS, path traversal e afins).

Esta release não é um marco de linguagem nova, é o tipo de atualização incremental que a maioria dos times nem percebe acontecer, já que o GitHub faz deploy automático de cada versão do CodeQL para quem usa code scanning no GitHub.com. Mesmo assim, tem uma mudança quebradora escondida no meio das melhorias, e vale entender o que muda antes que um alerta apareça (ou desapareça) sem explicação.

O que mudou no GitHub Actions

O foco em Actions faz sentido: um workflow mal escrito é uma porta de entrada direta pro repositório e pros segredos do time. O CodeQL 2.26.3 mexe em várias queries que tratam justamente desses cenários.

A análise agora reconhece dados não confiáveis vindos de github.event.merge_group, em workflows disparados pelo evento merge_group (usado por merge queues). É o mesmo raciocínio de sempre no CodeQL Actions: qualquer campo controlável por quem abre um PR ou dispara um evento externo é uma fonte de dado potencialmente hostil, e precisa ser rastreado até onde ele pode causar estrago.

Algumas queries ganharam precisão relevante:

• actions/envvar-injection/critical passou a exigir que a fonte não confiável e o contexto privilegiado venham do mesmo evento de trigger. E deixou de tratar labels de PR head como capazes de injeção, pela razão técnica simples de que labels não podem conter quebras de linha. Menos falso positivo.
• As queries de cache poisoning (code-injection, direct-cache, poisonable-step) agora consideram acesso somente-leitura ao cache em triggers de baixa confiança no branch padrão. Elas mantêm resultado só para triggers que o GitHub de fato permite escrever naquele escopo de cache. Ou seja: menos alerta ruidoso sobre cenários onde o atacante não conseguiria envenenar o cache mesmo.
• actions/cache-poisoning/poisonable-step e actions/untrusted-checkout/critical agora iniciam o caminho do dado na expressão que controla o checkout não confiável, o que torna o alerta mais fácil de seguir na hora de investigar.
• O evento schedule passou a ser classificado corretamente ao decidir se um workflow pode ser disparado externamente.

Houve também um ajuste de performance na query actions/output-clobbering/high, que sofria com entrada de expressão regular não escapada, e agora não reporta mais filtros jq simples cujo output continua sendo JSON.

A mudança quebradora: adeus SelfHostedQuery

Essa merece atenção de quem escreve queries customizadas. O CodeQL removeu o módulo codeql.actions.security.SelfHostedQuery. O motivo declarado é honesto: os labels de runner não distinguem de forma confiável um self-hosted runner de um runner gerenciado pelo GitHub. Ou seja, o módulo prometia uma classificação que na prática era chute.

Se você tem query própria que importa esse módulo, ela vai parar de compilar. Não é o fim do mundo, mas é o tipo de coisa que passa despercebida até o pipeline de análise falhar. Aqui vale o princípio geral de segurança estática: preferir não ter um sinal a ter um sinal errado. Um detector de self-hosted runner que erra metade das vezes gera ruído que treina o time a ignorar alertas, e alerta ignorado é pior que alerta ausente.

JavaScript, TypeScript e Vue

Do lado JS/TS, a novidade mais estrutural é a possibilidade de modelos customizados referenciarem arquivos específicos usando um nome de pacote no formato file:. Isso permite definir sources e sinks a partir dos exports públicos de um arquivo, algo útil pra quem tem código interno que não vem de pacote npm mas precisa ser tratado como fronteira de confiança.

A modelagem de framework também avançou:

• Foram adicionados flow models para os helpers da Composition API do Vue: ref, shallowRef, toRef, reactive e computed. Sem isso, o rastreamento de dados perdia o rastro assim que passava por um desses wrappers reativos.
• O useRoute() do Vue Router agora é reconhecido como fonte de dado remoto client-side, incluindo query, params, path, fullPath e hash. Faz sentido: tudo que vem da URL é atacante-controlável.
• Controllers Sails Action2 têm suas propriedades inputs declaradas tratadas como fonte remota, o que deve melhorar resultados de js/path-injection.
• Queries usando o modelo de ameaça de resposta agora rastreiam dados de resposta client-side embrulhados em promise até o valor de resolução da promise, melhorando js/xss.
• A js/missing-rate-limiting passou a reconhecer o pacote @fastify/rate-limit como limitador de taxa.

Pra C/C++ entraram modelos de fonte para RegQueryValue e funções relacionadas do header winreg.h do Windows. E em Ruby, uma mudança que reduz falso positivo: entrada de biblioteca para gems vendorizadas saiu do conjunto de fontes de taint, o que ajuda quem usa vendoring.

O que isso muda na prática pro dev brasileiro

Se você usa code scanning no GitHub.com, não precisa fazer nada: a versão já está rodando. O efeito prático é uma redução de ruído nas queries de Actions e melhor cobertura de código Vue e TypeScript. Times que sofriam com falsos positivos de cache poisoning ou envvar injection devem ver a lista de alertas encolher, e isso é um ganho real de sinal/ruído, não uma regressão de segurança.

Dois grupos precisam agir:

1. Quem escreve queries CodeQL customizadas e usava SelfHostedQuery: atualize antes que o pipeline quebre.
2. Quem roda GitHub Enterprise Server: a distribuição automática ainda não chegou. Uma release futura do GHES vai incluir essa versão; até lá, dá pra fazer upgrade manual do CodeQL se você precisa das melhorias agora.

Vale lembrar o trade-off geral de análise estática nesse tipo de update: cada aumento de precisão que corta falso positivo também pode, teoricamente, deixar passar um caso de borda que antes era pego por acidente. Na prática o saldo aqui é positivo, mas se seu time depende de code scanning como controle de compliance, faz sentido comparar a contagem de alertas antes e depois pra entender o que mudou no seu repositório específico. O changelog completo lista todas as alterações versão a versão.

Fonte: GitHub Changelog