O comando que ninguém viu: a injeção oculta em GitHub Actions e a ilusão da esteira confiável

Em 1º de setembro de 2026, uma sequência automatizada publicou pelo menos 83 itens maliciosos — entre issues, pull requests e comentários — em 61 repositórios públicos no GitHub. Desses registros, 77 entraram no ar em 43 minutos e os seis restantes nos dois minutos seguintes, enviados por 74 contas distintas, segundo os pesquisadores Zvika Babo e Gabi Nakibly, da Radware, em reportagem exclusiva do The Register publicada em 29 de outubro de 2026. Na síntese técnica da ReleaseLock (01/11/2026), que consolida os números do relato da Radware, a primeira leva ocorreu entre 11h26 e 12h10 UTC; no conjunto dos 83 itens das duas levas, os comandos shell distribuíram-se em 31 títulos, 17 corpos de descrição e 35 comentários.

Não havia falha nos servidores do GitHub nem exploração de memória na máquina virtual do runner. O alvo foi a interpolação direta de entradas externas em scripts shell do GitHub Actions, combinada — nos corpos e comentários — com comentários HTML (<!-- ... -->) invisíveis na página renderizada pelo navegador. Enquanto um mantenedor via apenas uma dúvida comum na interface web, um workflow vulnerável acionado pela abertura do item substituía a expressão ${{ ... }} pelo texto bruto antes de chamar o bash e executava o comando para recolher variáveis de ambiente e transmiti-las a um servidor externo.

Receber a postagem não equivalia a ser comprometido: nos logs de execuções reais examinados pela Radware, o comando injetado rodou dentro do ambiente de automação em dois casos, sem confirmação de obtenção de escrita no repositório, alteração de código-fonte ou impacto sobre software distribuído a terceiros. Ainda assim, o episódio expõe um erro recorrente de arquitetura operacional: acoplar gatilhos abertos a qualquer conta externa ao mesmo job que detém tokens de escrita e segredos de publicação. Este texto é uma análise documental apurada em 05/11/2026: não executamos cargas de exploração nem reproduzimos disparos em repositórios; declarações externas e interpretações nossas estão identificadas como tais.

O que aconteceu em 1º de setembro — e o que os dados provam

Reconstituir o episódio exige separar o que cada fonte documenta. Em 05/11/2026, o endereço do blog técnico da Radware respondia apenas com uma tela de proteção contra leitores automatizados; por regra de método, não citamos como leitura direta páginas que não puderam ser abertas na íntegra no momento da apuração. Os dados e as declarações dos autores foram verificados na reportagem de Jessica Lyons no The Register (29/10/2026), que recebeu acesso prévio à pesquisa e entrevistou Nakibly e Babo, e confrontados separadamente com o levantamento de Cassie Crossley na ReleaseLock (01/11/2026). Já a nota em português do Estadão/TecMundo (04/11/2026), gancho inicial desta pauta, grafou 67 itens na primeira leva mais seis na sequência — soma que fecharia em 73 e contradiz o total de 83 ataques do próprio texto.

Até 13 de outubro de 2026, Babo e Nakibly catalogaram 83 itens com carga verificada em 61 repositórios públicos. Como dezenas de contas enviaram o mesmo tipo de payload, no mesmo dia, dentro de uma janela estreita de 45 minutos e apontando para a mesma infraestrutura receptora, os pesquisadores concluíram tratar-se de atividade coordenada, provavelmente operada por um único indivíduo. Muitas das 74 contas do GitHub utilizadas exibiam histórico prévio legítimo de desenvolvimento, o que indica uso provável de contas comprometidas.

Os alvos listados pela Radware ao The Register abrangem frameworks de inteligência artificial, segurança, infraestrutura de contêineres, bancos de dados e utilitários de estação de trabalho. Entraram na varredura agno-agi/agno (42,7 mil estrelas no estudo; 43.072 na API do GitHub às 14h30 UTC de 05/11/2026), ToolJet/ToolJet (41,1 mil; 41.202 em 05/11), google/langextract (38,9 mil; 39.272), aquasecurity/trivy (38,4 mil; 39.011), CopilotKit/CopilotKit (38 mil; 38.529), podman-container-tools/podman (33 mil; 33.183), QwenLM/qwen-code (28,5 mil; 29.022), mlflow/mlflow (28,4 mil; 28.691), discordjs/discord.js (26,8 mil; 26.828), cilium/cilium (25,6 mil; 25.779), brave/brave-browser (23,9 mil; 24.115), dotnet/maui (23,3 mil; 23.327), Homebrew/homebrew-cask (22,2 mil; 22.284), github/docs (21 mil; 21.302), apache/doris (16 mil; 16.184) e PX4/PX4-Autopilot (12,8 mil; 12.970).

Essa relação pede uma ressalva imediata: figurar entre os 61 alvos não significa ter esteira vulnerável. Como observou Babo ao The Register, o autor do disparo não precisa invadir o repositório nem acessar seu código para tentar o ataque; qualquer conta do GitHub pode abrir uma issue ou comentar em repositório público. Onde não há workflow atrelado ao evento — ou onde o texto entra isolado como dado —, a carga oculta permanece inerte.

Os próprios pesquisadores registraram o limite do impacto observado. Nos logs de execuções reais, encontraram dois casos em que o comando malicioso efetivamente rodou no ambiente de automação. Não conseguiram determinar, contudo, se o atacante obteve permissões de escrita, alterou código ou atingiu usuários finais; Nakibly classificou explicitamente como estimativa da equipe a hipótese de que o alvo final fosse envenenar a cadeia de suprimentos. Todos os mantenedores foram avisados, e a maior parte dos itens foi fechada ou corrigida, embora a equipe não tenha confirmado o desfecho na totalidade dos projetos.

Duas camadas, dois leitores: HTML oculto na interface, substituição literal no runner

A campanha explorou a diferença entre como o GitHub exibe texto para pessoas e como o GitHub Actions monta scripts para máquinas. São dois processadores independentes, regidos por especificações próprias.

Na interface web, corpos de issues, descrições de pull requests e comentários passam pelo GitHub Flavored Markdown (GFM, versão 0.29-gfm), superconjunto formal do CommonMark 0.29 cuja regra para comentários permanece idêntica no CommonMark atual (versão 0.31.2). Nas seções 4.6 (HTML blocks) de ambas as especificações e na seção de Raw HTML (6.10 no GFM; 6.6 no CommonMark 0.31.2), trechos entre <!-- e --> constituem HTML bruto válido. A extensão da seção 6.11 do GFM (Disallowed Raw HTML) escapa nove tags específicas que alteram o parser de HTML aninhado — <title>, <textarea>, <style>, <xmp>, <iframe>, <noembed>, <noframes>, <script> e <plaintext> — e deixa as demais intactas, seguidas pelo pós-processamento de sanitização descrito na seção 1.1; como comentários HTML não são exibidos na árvore visual do navegador, o trecho permanece oculto na leitura de tela.

Em corpos e comentários, o resultado prático é invisibilidade diante da revisão humana: o colaborador lê duas linhas de texto plausível no navegador, enquanto o payload permanece guardado apenas no Markdown bruto e na API. Já nos 31 registros em que a carga entrou no título do item, conforme o detalhamento citado pela ReleaseLock, não há renderização de bloco Markdown capaz de ocultar o comentário. Ali a velocidade bastava ao invasor: segundo Nakibly relatou ao The Register, o workflow vinculado ao evento dispara em cerca de um segundo após a criação do registro, antes de qualquer moderação manual.

A execução indevida ocorre na segunda camada, quando um arquivo .github/workflows/*.yml reage a eventos externos (issues, issue_comment, pull_request ou pull_request_target) e interpola expressões de contexto direto em uma etapa run:. O defeito está documentado desde agosto de 2021 por Jaroslav Lobačevski no estudo Keeping your GitHub Actions and workflows secure Part 2: Untrusted input, do GitHub Security Lab, e na referência oficial de uso seguro do GitHub Actions.

Antes de entregar o bloco run: ao shell (bash por padrão no Linux), o motor do GitHub Actions resolve todas as expressões ${{ ... }} e grava o texto literal resultante em um arquivo temporário de script. Não existe escape automático para a gramática do shell. Se a etapa contém echo "${{ github.event.issue.body }}" e o autor da issue enviou aspas duplas, quebras de linha, ponto e vírgula ou $(...), o texto externo fecha o comando echo e injeta instruções arbitrárias no interpretador da máquina virtual.

Na referência de uso seguro, o GitHub aponta duas correções: processar o valor como argumento de uma JavaScript Action (with:) ou, em scripts inline, atribuir a expressão a uma variável intermediária em env::

# Origem: docs.github.com/en/actions/reference/security/secure-use
- name: Check PR title
  env:
    TITLE: ${{ github.event.pull_request.title }}
  run: |
    if [[ "$TITLE" =~ ^octocat ]]; then
    echo "PR title starts with 'octocat'"
    exit 0
    else
    echo "PR title did not start with 'octocat'"
    exit 1
    fi

Declarar o campo em env: muda o canal pelo qual o dado chega ao sistema operacional. O valor de github.event.pull_request.title vai direto para a memória de ambiente do processo e não participa da geração do arquivo de script. Quando o bash lê "$TITLE" entre aspas duplas, uma carga como a"; ls $GITHUB_WORKSPACE" permanece confinada como string de comparação e o ataque falha.

Leitura nossa: é a mesma fronteira que separou consultas SQL concatenadas de prepared statements há duas décadas. Equipes que jamais aceitariam concatenar entrada de formulário em uma query SQL costumam tratar .github/workflows/ como script auxiliar e interpolam github.event.issue.body, github.event.comment.body ou github.head_ref direto no shell. Em repositório aberto a issues ou forks, todos esses campos são entradas não confiáveis.

Da variável de ambiente ao artefato publicado: onde a cadeia de suprimentos quebra

Quando o comando injetado roda no runner, seu alvo imediato são as variáveis de ambiente e as credenciais acessíveis ao job. Dimensionar esse risco exige olhar para as regras atuais de permissão do GitHub e para o efeito prático de uma credencial de escrita sobre artefatos distribuídos.

Todo job recebe automaticamente no início da execução um GITHUB_TOKEN único, credencial temporária que expira quando o job termina, segundo a documentação conceitual de segurança do GITHUB_TOKEN. Não é verdade que qualquer repositório novo hoje nasça com escrita irrestrita: conforme a documentação de gerenciamento de configurações de GitHub Actions, novos repositórios em contas pessoais já vêm limitados por padrão à configuração restrita — leitura apenas nos escopos contents e packages — e bloqueiam a criação ou aprovação de pull requests por workflows.

A superfície real de captura persiste em três frentes:

1. Herança organizacional legada: repositórios criados dentro de organizações herdam a política definida na organização. Onde a organização manteve a configuração permissiva antiga (acesso de leitura e escrita para todas as permissões), qualquer workflow sem bloco permissions: explícito recebe escrita automática.
2. Jobs mistos com escrita declarada: workflows que acumulam triagem externa e automação administrativa costumam declarar permissions: contents: write no topo do arquivo. Embora o GITHUB_TOKEN não ignore sozinho regras ativas de proteção de branch que exijam revisão humana, contents: write basta para criar tags, gravar em branches desprotegidas e substituir arquivos em releases mutáveis.
3. Segredos estáticos (Secrets): gatilhos como issues, issue_comment e pull_request_target rodam no contexto do repositório base. Se o job montar tokens do npm, PyPI, registros de contêineres ou chaves de nuvem sem federação OIDC de escopo mínimo, uma leitura do ambiente expõe credenciais que continuam válidas fora do GitHub.

O impacto concreto de uma credencial com escrita sobre releases abertas ficou demonstrado em outubro de 2026, nove dias antes da divulgação do estudo da Radware, no aviso oficial GHSA-862f-55f5-vmvw da OVHcloud, publicado em 20/10/2026.

Em 19 de outubro de 2026, das 14h47 às 16h21 (UTC+2), uma conta comprometida de desenvolvedor da OVHcloud substituiu os binários publicados nas versões v0.11.0 a v0.15.0 do repositório ovh/ovhcloud-cli (macOS, Linux e Windows) por executáveis maliciosos. Nem o código-fonte nem a esteira de compilação foram tocados: apenas os arquivos anexados às releases existentes foram trocados, permanecendo disponíveis por 1 hora e 33 minutos e acumulando cerca de 250 downloads até a remoção e o lançamento da versão limpa v0.16.0. Como registra a análise da ReleaseLock, o invasor trocou também o checksums.txt, e a adulteração só caiu em menos de duas horas porque o pipeline de um cliente fixava o hash SHA-256 anterior do pacote. No diagnóstico da própria OVHcloud, a falha central foi o repositório não estar configurado para garantir imutabilidade das releases.

Leitura nossa: os dois casos mostram as duas pontas do mesmo circuito. A campanha de 1º de setembro tentou pescar credenciais na entrada da esteira; o incidente de 19 de outubro na OVHcloud mostrou o que uma credencial com escrita faz em 93 minutos quando encontra releases mutáveis — contamina quem baixa o binário sem alterar uma linha do código-fonte.

A tabela-eixo: o que cada desenho de fronteira assume, autoriza e cobra da equipe

A decisão de engenharia diante de automações no GitHub está no que cada topologia de workflow assume sobre dados externos, no raio de alcance em caso de falha e no trabalho humano que transfere para a operação:

sequenceDiagram
    autonumber
    actor Atacante as Atacante Externo
    participant GH as GitHub API / Webhook
    participant UI as Interface Web (Navegador)
    participant Runner as Runner do GitHub Actions
    participant C2 as Servidor C2 do Atacante

    Atacante->>GH: Abre Issue com carga oculta:<br/>comentário HTML com comando curl injetado
    GH-->>UI: Renderiza CommonMark (comentário HTML invisível na interface)
    GH->>Runner: Dispara evento 'issues: opened'
    activate Runner
    Note over Runner: Workflow vulnerável avalia inline:<br/>run: echo "${{ github.event.issue.body }}"
    Runner->>Runner: Bash quebra sintaxe e executa comando injetado
    Runner->>C2: Exfiltra GITHUB_TOKEN (escrita) e Secrets
    deactivate Runner

A falha da visibilidade humana: Comentários HTML no formato <!-- ... --> são omitidos pelo renderizador CommonMark na interface do GitHub. Um chamado que aparenta ser benigno no navegador transporta comandos arbitrários que o runner avalia antes de qualquer triagem humana.

Leitura nossa: as equipes escorregam para a primeira linha porque ela resolve uma tarefa visível em quinze minutos sem custo aparente. A terceira linha cobra o preço adiantado em desenho e revisão; em contrapartida, faz com que uma tentativa de injeção bata em um ambiente sem segredos para roubar.

Quando o leitor do ticket passa a ser um agente de código

Um detalhe da apuração da Radware conecta diretamente o incidente de setembro às arquiteturas atuais de desenvolvimento assistido por IA: segundo relataram ao The Register, Babo e Nakibly descobriram a campanha de injeção shell enquanto investigavam injeção de prompt (prompt injection) no GitHub. Procuravam instruções ocultas desenhadas para desviar agentes de IA e encontraram comandos de shell viajando pelo mesmo esconderijo de comentários HTML.

As duas superfícies hoje ocupam o mesmo pipeline. Organizações vêm ligando agentes de código a eventos de issues e pull requests para diagnosticar bugs, resumir chamados e propor correções. O próprio GitHub documenta esse modelo no guia oficial de Agentic Workflows no GitHub Actions e no projeto gh-aw (v1.0.1, lançada em 27/10/2026), que executa motores como GitHub Copilot CLI, Claude Code, OpenAI Codex ou Gemini CLI dentro de runners da plataforma.

Quando quem lê o ticket é um modelo de linguagem com acesso a ferramentas, isolar o texto em env: deixa de resolver o problema sozinho. Transferir github.event.issue.body para uma variável de ambiente protege o bash, mas o processo do agente lê essa variável em seguida e injeta o texto bruto na janela de contexto do modelo. O comentário <!-- ... --> que o revisor humano não viu no navegador entra integralmente no prompt, podendo instruir o agente a ler variáveis locais, inspecionar configurações ou embutir dados em artefatos de saída.

A arquitetura oficial do gh-aw explicita o tamanho dessa restrição: o job principal do agente roda em contêiner com permissões somente leitura e controle de saída de rede, sem permissão direta para gravar no repositório. Qualquer ação externa precisa ser descrita em artefatos estruturados e validada por jobs posteriores determinísticos — os safe outputs — com permissões restritas por operação.

Ainda assim, até a camada de transição entre agente e repositório exige auditoria fina. Em 27 de agosto de 2026, o projeto gh-aw publicou o aviso crítico GHSA-8h78-hpm7-29gg (CVSS v4 9.1, corrigido na v0.85.4). Nas versões 0.83.3 a 0.85.3, os jobs de safe output gravavam stdout e stderr brutos no artefato safe-outputs-items. Quando o workflow usava GH_AW_CI_TRIGGER_TOKEN para criar ou atualizar um pull request, um comando git config com o cabeçalho de autorização em Base64 podia ir para o artefato antes do mascaramento de segredos do runner, permitindo que quem baixasse o artefato decodificasse o token. E atualizar apenas a CLI local não bastava: era obrigatório rodar gh aw upgrade e commitar os arquivos .lock.yml regenerados para substituir as ações fixadas por SHA.

Leitura nossa: colocar um agente na triagem de issues não substitui a engenharia de fronteira do CI/CD; dobra a exigência sobre ela. Além de impedir que texto vire comando no shell, a esteira precisa limpar marcações ocultas na ingestão, negar credenciais ao ambiente em que o modelo raciocina e inspecionar os artefatos que cruzam de um estágio ao outro.

flowchart LR
    subgraph S1["Estágio 1: Triagem com Agente"]
        direction TB
        Evt["Entrada Não Confiável (Issue/PR)"] --> RunA["Runner em Contêiner Isolado"]
        RunA --> Agent["Agente de IA (gh-aw / CLI)"]
        PermA["Permissões: contents: read<br/>Sem acesso a Secrets ou escrita"]
    end

    subgraph S2["Estágio 2: Safe Outputs"]
        direction TB
        Agent --> Schema["Validação Rígida de Schema (JSON)"]
        Schema --> Art["Artefato Sanitizado (safe-outputs)"]
    end

    subgraph S3["Estágio 3: Execução Privilegiada"]
        direction TB
        Art --> RunB["Job de Escrita / Release"]
        RunB --> Actions["Criação de PR / Assinatura de Tag"]
        PermB["Permissões: contents: write<br/>Credenciais restritas por ambiente"]
    end

    S1 --> S2 --> S3

O risco transferido para a janela de contexto: Confinar a entrada em variáveis de ambiente protege o interpretador shell, mas o texto não sanitizado entra na janela de contexto do modelo. Se o agente tiver permissão de escrita, a injeção de prompt assume o controle da esteira sem precisar quebrar o bash.

Contra-evidência: dois casos em 61 justificam redesenhar a esteira?

A melhor objeção ao esforço de reestruturar workflows vem dos próprios números apurados pelo The Register: em 59 dos 61 repositórios visados não apareceu evidência de execução nos logs analisados, e nos dois restantes não se confirmou adulteração de código ou de pacotes. Se o GitHub já aplica leitura restrita por padrão em novos repositórios pessoais e oferece releases imutáveis, endurecer pipelines não seria custo excessivo para um risco residual?

Três fatos operacionais refutam essa leitura.

Primeiro, a assimetria econômica do disparo. Publicar 83 itens em 45 minutos exige um script simples e nenhuma informação interna sobre os alvos; para quem mantém software usado por milhares de organizações, uma única execução bem-sucedida em job com token de publicação basta para expor toda a distribuição do pacote. Confirmar execução em dois repositórios de alta visibilidade em uma varredura cega prova que o padrão vulnerável continua ativo em produção.

xychart-beta
    title "Assimetria da Campanha de Injeção em CI/CD (Radware / The Register)"
    x-axis ["Repositórios Alvejados", "Cargas Injetadas", "Duração do Disparo (min)"]
    y-axis "Métricas da Campanha" 0 --> 100
    bar [61, 83, 45]

Segundo, cada trava nativa cobre apenas um trecho do caminho. Conforme a documentação de Immutable releases, a imutabilidade impede alterar ou apagar ativos e tags após a publicação da release — barreira que teria evitado a troca dos binários v0.11.0 a v0.15.0 no ovhcloud-cli. Ela não impede, porém, que um comando injetado exfiltre chaves de nuvem ou tokens do npm e do PyPI, nem impede a publicação de uma versão nova já adulterada com a credencial roubada. Do mesmo modo, o padrão restrito em contas pessoais novas não corrige políticas antigas de organizações nem protege Secrets declarados no job.

Terceiro, desligar toda automação de issues também erra o alvo: aumenta o trabalho manual da equipe e preserva vulnerabilidades idênticas em gatilhos internos que interpolam nomes de branch (github.head_ref) ou mensagens de commit sem isolamento.

O preço operacional e a posição para quem governa repositórios

Nossa posição é inequívoca: arquivos em .github/workflows/ são código em produção com acesso a credenciais e devem obedecer ao mesmo regime de contrato de dados, menor privilégio e verificação estática exigido da aplicação principal.

Sustentar essa decisão cobra quatro rotinas humanas permanentes: revisar mudanças em workflows com foco em fronteira de privilégio; separar fluxos cômodos de job único em estágios distintos de leitura e escrita; manter verificação estática bloqueando merges inseguros; e gerir escopo e rotação de segredos. É um custo contínuo, porém previsível e menor que o de responder às cegas a um vazamento de credencial de build.

Para líderes de engenharia e gestores de TI, a execução resume-se a cinco controles auditáveis:

1. Fixar GITHUB_TOKEN em leitura mínima na organização e declarar permissions: por job. Nas configurações de permissões de workflow da organização e de cada repositório, selecione a opção restrita de leitura apenas para contents e packages e mantenha desmarcada a criação ou aprovação de pull requests por workflows, seguindo a documentação de governança do GitHub. Conceda escrita apenas ao job isolado que efetivamente publica ou etiqueta.
2. Banir ${{ ... }} de entradas externas dentro de run:. Aplique a referência oficial de uso seguro: processe argumentos em actions tipadas (with:) ou passe campos github.event.* e github.head_ref exclusivamente pelo bloco env:, lendo-os entre aspas duplas no shell ("$VAR") ou via process.env / os.environ.
3. Isolar pull_request_target e eventos públicos de qualquer checkout não confiável. Nunca execute actions/checkout do código de um fork nem scripts do autor externo no mesmo job que recebe segredos ou permissão de escrita.
4. Bloquear regressões com análise estática de workflows no CI. Integre o actionlint (v1.7.12) para validação sintática e checagem de scripts e o zizmor (v1.32.0), cuja auditoria template-injection aponta expansões inseguras de contexto, gatilhos de risco e permissões excessivas antes do merge.
5. Ativar releases imutáveis e higienizar entradas antes de agentes de código. Habilite releases imutáveis onde houver distribuição de binários e, em fluxos com agentes — próprios ou via GitHub Agentic Workflows —, remova comentários HTML ocultos (<!-- ... -->) na ingestão, mantenha o modelo em job somente leitura sem segredos e audite os arquivos .lock.yml e artefatos intermediários.

Como sintetizou Nakibly ao The Register, ninguém impede que terceiros abram issues tentando injetar comandos em projetos públicos; o que está sob controle da engenharia é impedir que o workflow trate texto externo como código.

Notas de método

• Data do snapshot e versões conferidas: apuração concluída em 05/11/2026. Especificações e releases abertas na fonte nesta data: CommonMark 0.31.2 (28/01/2024), GitHub Flavored Markdown 0.29-gfm (06/04/2019, derivado do CommonMark 0.29), actionlint v1.7.12 (30/03/2026), zizmor v1.32.0 (02/11/2026) e github/gh-aw v1.0.1 (27/10/2026). As estrelas dos 16 repositórios listados foram consultadas às 14h30 UTC de 05/11/2026 na API REST pública do GitHub ao lado dos números registrados na época do relatório da Radware.
• Caráter documental: análise estritamente documental; não enviamos payloads de teste, não abrimos issues em repositórios alheios e não executamos scripts de exploração.
• Acesso às fontes e endereços canônicos: em 05/11/2026, o endereço do post da Radware (radware.com/blog/inside-a-github-supply-chain-attack-campaign/) retornava uma página de verificação contra leitores automatizados (Loader page), sem o texto do estudo. Conforme nossa regra de evidência, não contornamos o bloqueio nem simulamos leitura direta: apuramos os dados e as declarações de Nakibly e Babo pela reportagem exclusiva do The Register (29/10/2026), que teve acesso antecipado ao trabalho e entrevistou os autores, e pela síntese técnica da ReleaseLock (01/11/2026), atribuídas separadamente. Na mesma data, páginas HTML de repositórios e avisos em github.com apresentaram latência intermitente em cache frio (HTTP 504 na raiz github.com/github/gh-aw e em parte das consultas às visualizações web de GHSA-862f-55f5-vmvw e GHSA-8h78-hpm7-29gg); por isso, apontamos as ferramentas diretamente para suas páginas de release (v1.7.12, v1.32.0 e v1.0.1, estáveis em HTTP 200), a arquitetura para github.github.com/gh-aw e conferimos o conteúdo integral dos dois avisos tanto nas respostas HTTP 200 das páginas HTML quanto nos endpoints correspondentes da API REST do GitHub (api.github.com). Substituímos ainda o caminho antigo /research/ do GitHub Security Lab pelo endereço ativo /resources/github-actions-untrusted-input/ e a organização antiga woodruffw/zizmor por zizmorcore/zizmor.
• Divergência descartada na imprensa secundária: a matéria do Estadão/TecMundo (04/11/2026) menciona 67 itens maliciosos em 43 minutos seguidos de outros seis, mantendo o total de 83. Excluímos o número 67 por erro aritmético (67 + 6 = 73 ≠ 83) diante do registro original 77 + 6 = 83.
• Fatos apurados versus leitura nossa: as contagens da campanha de 01/09/2026, o aviso GHSA-862f-55f5-vmvw da OVHcloud, o aviso GHSA-8h78-hpm7-29gg do gh-aw e o funcionamento do GITHUB_TOKEN, das expressões ${{ ... }} e do CommonMark/GFM provêm das fontes linkadas em cada frase. A tabela-eixo, o paralelo com contratos de dados e a ordenação dos controles operacionais são leitura nossa, assinalada no corpo. As 82 alegações factuais externas passaram por verificação independente dedicada em 05/11/2026; nove apontamentos da conferência cruzada (escopo aritmético da distribuição 31/17/35, numeração de seção entre GFM 0.29-gfm e CommonMark 0.31.2, link exato de expiração do GITHUB_TOKEN, latência intermitente em github.com, precisão de paráfrases e atualização intradiária de estrelas) foram corrigidos antes desta entrega.
• Imagem de abertura: ilustração gerada por IA a partir do tema deste artigo — o card Issue revelando <!-- ... --> e o fluxo env: → run: em GitHub Actions na paleta da marca —, usada como cena editorial (via B do guia visual), sem retratar tela ou repositório específico.