Ações do GitHub vazam segredos quando a saída do Miri é armazenada em cache.

A equipe de resposta de segurança Rust foi notificada de que o Miri armazena todas as variáveis de ambiente emalvo/Permitindo que segredos persistam em caches.

Embora não seja, em si, uma vulnerabilidade, quando combinada com o comportamento de cache do GitHub Actions, é possível que isso exponha segredos para solicitações de pull (PRs).

Visão Geral

As ações do GitHub permitem o cache de diretórios entre execuções. Configurações típicas permitem execuções de CI (Integração Contínua) emTexto: principal(e outras filiais) paraEscreverpara cachear, e os PRs só podemlerdo cache (prevenindo envenenamento do cache). Projetos em Rust tendem a acelerar a CI ao cachear binários construídos porcargo installe às vezes o conteúdo detarget/.

O CI de PRs pode ser acionado por qualquer um que possa abrir PRs no seu repositório. O GitHub exige aprovação de mantenedor para oPrimeiroPR, mas futuros PRs reiniciarão a CI em cada push. Qualquer pessoa que já tenha aplicado uma mudança pode acionar uma execução de CI extraindo informações de um cache.alvo/E então, eles cobrem seus rastros ao empurrar um segundo commit para o PR.

O GitHub às vezes esconde commits sobrescritos em sua interface de usuário, tornando esse tipo de ataque mais difícil de detectar. Os logs de execução de CI e os commits sobrescritos também são excluídos após alguns meses.

Quandocargo miriQuando o comando é invocado, Miri precisa manter as variáveis de ambiente relevantes entre as execuções.¹O código atual para fazer isso é alcançado ao armazenarTodas as variáveis de ambiente paraalvo/Isso, é claro, persiste quandoalvo/O texto: "is cached" está em português brasileiro como: "está em cache."

Se o seu ambiente contivesse segredos, esses podem ser acessados agora por PRs via o cache.

Nossa correção

Nossosolução a curto prazopara isso é fazer com que Miri preserve apenasCARGO_*.variáveis de ambiente (excetoCARGO_*_TOKEN) eOUT_DIRA longo prazo, Miri e o cargo podem descobrir maneiras melhores de informar Miri sobre a lista relevante de variáveis de ambiente. Observe que essa correção pode não estar disponível na versão noturna ainda.

Também realizamos uma varredura de ecossistema nos repositórios do GitHub e identificamos 1 repositório com esse problema e 7 repositórios que não parecem vulneráveis, mas devem ter cautela de qualquer forma. Entramos em contato com os mantenedores.

Estou afetado?

É provável que nossa varredura tenha sido imperfeita, então recomendamos que você verifique suas próprias configurações do GitHub Actions se executar Miri.

Você é vulnerável se:

• Você executacargo miriem CI
• O passo que executaCargo Miri Tem acesso a segredosComo uma variável de ambiente:
  • Ao ser passado para o passo em si como uma variável de ambiente
  • Ao ser definido emenvPara o fluxo de trabalho
  • Ao serem passadas para uma etapa anterior que as mantém persistentes no ambiente de alguma forma.
• O fluxo de trabalho utilizado armazena em cache oAlvodiretório, geralmente realizado por meio deAções/cacheO texto fornecido já está em português brasileiro, portanto, não há necessidade de tradução. Texto: "ou"Texto: Swatinem/rust-cache
• O cache é acessível a PRs (comum e frequentemente o caso de uso pretendido).

Correções rápidas possíveis incluem:

• Desabilitando o cache para essa tarefa.
• Restringindo segredos a etapas nessa tarefa que não chamem Miri.
• Desabilitando temporariamente Miri.

Após concluído,por favor, limpe o cache.Considere rotacionar quaisquer segredos que possam ter vazado.

A liberação de Miri na próxima noite (2026-09-22) não terá mais esse problema.

Mesmo que você não gerencie a Miri,garanta que os trabalhos que podem escrever em caches públicos não tenham acesso a segredos. Muitos ferramentas não têm manuseio especial para segredos, e assumem que todo o ambiente pode ser escrito no sistema de arquivos.

Modelo de ameaça

Consideramos uma má prática ter um cache que possa ser facilmente contaminado por segredos.

Se o cache,target/for o alvo, vale a pena garantir que as entradas para processos que criamtarget/Texto: (qualquer coisa que invoque) Tradução: (qualquer coisa que invoque)Cargo/Miri/Rust não garante que as variáveis de ambiente sejam seguras de serem copiadas para o target.Não existem segredos disponíveis para serem acessados.Os comandos de construção/teste padrão raramente precisam de segredos ou tokens.Não há segredos ou tokens necessários para esses comandos.²Portanto, é principalmente uma questão de ter cuidado para não expor segredos como variáveis de ambiente para o trabalho inteiro.

Cargo/Miri/Rust não assegura a segurança das variáveis de ambiente contra serem copiadas para o target.(sem tradução, pois parece incompleto)Embora tratemos isso como uma questão de segurança e apliquemos correções por via de precaução, não é algo em que você deve confiar em geral. Além das ferramentas oficiais do Rust, é possível que scripts de construção realizem ações que levem o ambiente a ser armazenado em artefatos de compilação.

Agradecimentos

Agradecemos aPredrag Gruevskida OpenAI por nos informar sobre este problema. Além disso, a varredura do ecossistema foi realizada usando o acesso e créditos do Codex doados pela OpenAI, para os quais também lhes agradecemos.

A triagem e correção do problema foram realizadas por Manish Goregaokar, Ralf Jung, Ben Kimock, Weihang Lo, Jacob Finkelman, Walter Pearce, Josh Stone e Mark Rousskov.

1. O Miri é invocado várias vezes porcargo miriPor razões complicadas↩

2. Em teoria, poderia gerar scripts de construção lendo da rede↩