GitHub passa a detectar service tokens do Cloudflare Access vazados

Em 12 de novembro de 2026, o GitHub adicionou ao secret scanning um detector para o tipo de segredo cloudflare_access_service_token, da Cloudflare. Na prática, os service tokens do Cloudflare Access commitados em repositórios agora podem ser detectados automaticamente, segundo o changelog do GitHub.

O anúncio descreve dois caminhos. Em repositórios públicos, o token encontrado é reportado automaticamente à Cloudflare pelo programa de parceria do secret scanning. Em repositórios públicos ou privados, ele gera um alerta de secret scanning para o usuário.

O que é um service token do Cloudflare Access

Um service token do Cloudflare Access é um par formado por um Client ID e um Client Secret. Sistemas automatizados e aplicações usam esse par para acessar aplicações protegidas pelo Access, enviando os valores nos headers CF-Access-Client-Id e CF-Access-Client-Secret, como explica a documentação de service tokens da Cloudflare.

Pense nele como o crachá de um robô. O script não faz login como uma pessoa faria, então apresenta esse par de credenciais a cada requisição.

O formato do Client Secret mudou recentemente. Segundo o changelog da Cloudflare sobre o formato rastreável, segredos criados a partir de 26 de agosto de 2026 seguem o padrão cfast_ + 40 caracteres alfanuméricos + um checksum de 8 caracteres hexadecimais. O mesmo changelog publica uma regex pronta para esse padrão, útil para buscar segredos no seu código.

Os segredos no formato antigo continuam funcionando e não precisam ser rotacionados. Os dois formatos usam o mesmo Client ID e os mesmos headers.

O que acontece quando o token vaza em repositório público

O caminho do repositório público tem duas etapas, e cada uma vem de uma fonte diferente.

A primeira está no changelog do GitHub: segredos de parceiro encontrados em repositórios públicos são reportados automaticamente a quem emitiu o segredo pelo secret scanning partnership program. Neste caso, o emissor é a Cloudflare.

A segunda está no changelog da Cloudflare sobre recuperação de tokens vazados: depois de receber o reporte do GitHub, o Access desativa o token afetado e envia um e-mail aos administradores da conta.

Se liga na palavra: a Cloudflare diz desativa. O token fica parado até alguém agir, e isso tem consequência direta para o que depende dele.

E em repositório privado?

Em repositório privado, o que o changelog do GitHub descreve é o alerta de secret scanning para o usuário. Esse alerta vale tanto para repositórios públicos quanto privados.

O reporte automático à Cloudflare, segundo o anúncio, fica restrito aos repositórios públicos.

O anúncio não fala de planos, custos nem de requisitos de habilitação. Se você precisa saber isso para o seu caso, vale conferir direto na documentação do secret scanning do GitHub.

O que muda para quem usa service tokens em scripts, CI e agentes

Quem mais sente essa mudança é quem guarda service tokens em scripts, pipelines de CI e automações. Na nossa observação, isso também pode incluir código gerado por agentes de IA, que às vezes acaba colocando a credencial direto no arquivo sem revisão humana, mas isso é um alerta editorial, não algo descrito pelas fontes oficiais.

O efeito colateral é concreto. Se o token vazar em repositório público, ele pode ser desativado, e a automação que depende dele deixa de acessar a aplicação protegida pelo Access.

Por isso, o e-mail aos administradores da conta e o alerta no GitHub são sinais que valem acompanhar de perto. Um deles pode ser a explicação de um pipeline que quebrou do nada.

A ação verificável é simples: procure o prefixo cfast_ (ou a regex publicada no changelog da Cloudflare) no código versionado dos seus repositórios. Tome cuidado com um detalhe: essa busca só encontra segredos no formato novo. Para tokens mais antigos, procure por trechos que montam os headers CF-Access-Client-Id e CF-Access-Client-Secret com valores escritos direto no código.

Como reativar um service token reportado como vazado

Segundo o changelog da Cloudflare, um token reportado como vazado só pode ser reativado depois que o segredo for rotacionado. O procedimento descrito segue esta ordem:

1. Rotacione o Client Secret do token. Segredos vazados não têm período de carência: o segredo anterior é descartado na hora. O erro comum aqui é achar que o valor antigo segue valendo por um tempo.
2. Atualize os serviços que usam o token com o novo segredo, nos mesmos headers de sempre.
3. Reative o token.

A ordem importa. Reativar antes de distribuir o segredo novo só deixa os serviços tentando autenticar com um valor que já não existe.

Próximo passo

Faça um levantamento de onde os service tokens do Access ficam guardados hoje: repositórios, arquivos de configuração de CI e scripts soltos. Tudo que estiver em texto puro dentro de código versionado é candidato a sair dali.

Depois, confira na documentação do GitHub, indicada no próprio changelog, a lista completa de segredos suportados pelo secret scanning. Se o seu fluxo usa agentes para gerar código, revisar o diff antes do commit continua sendo o filtro mais barato que existe 🙂.

Veja mais exemplos práticos no canal Hora de Codar. Se quiser aprofundar o contexto, veja 46% Dos Tokens Do Seu Agente Vão Pro Lixo (FastContext Resolve).