Em 11 de novembro de 2026, a Cloudflare anunciou que o secret scanning do GitHub passou a reconhecer segredos de service tokens do Cloudflare Access expostos em repositórios públicos. O GitHub avisa a Cloudflare, o Access desativa o token afetado e manda e-mail para os administradores da conta. Antes disso, conter o vazamento dependia de alguém perceber e trocar o segredo.
Service token é a credencial que o Access usa para máquinas: um par de Client ID e Client Secret que pipelines de CI, scripts, crons e serviços enviam nos cabeçalhos para passar por uma aplicação protegida sem login de pessoa.
O que muda na prática
Duas coisas, e a segunda pesa mais na operação.
A primeira é a desativação automática. A Cloudflare não pergunta antes: o token para de autenticar assim que o relatório chega. Qualquer integração que dependa dele começa a receber bloqueio do Access.
A segunda é a regra de recuperação. Um token marcado como vazado só volta a funcionar depois que o segredo é trocado, e essa troca não aceita período de transição. Na rotação comum do Access dá para manter o segredo antigo válido por um tempo enquanto os serviços são atualizados; no token vazado, o segredo anterior é descartado na hora. Pela API, tentar religar o token antes da rotação retorna 409, e pedir uma data futura em previous_client_secret_expires_at retorna 400. A rotação também não religa o token sozinha: é preciso ligar de novo depois de distribuir o segredo novo. O Client ID não muda.
Para auditoria, a API passa a devolver leak_reported_at, leak_reporter e leak_report_url, com quando e onde o vazamento foi encontrado. A rotação apaga esses campos, então o histórico fica nos logs de atividade administrativa.
Quem precisa olhar isso
Times que usam o Access para proteger painéis internos, APIs de staging ou ferramentas administrativas e autenticam automações com service token. O risco concreto está em repositório público: projeto open source com workflow de deploy, repositório de exemplo publicado por engano, fork público de código interno.
Quem nunca expôs um segredo não sente diferença. Quem expôs ganha uma proteção que antes não tinha, mas também uma parada de serviço sem aviso prévio, no momento em que o GitHub encontrar o segredo, seja qual for o horário.
O que fazer agora
Não há prazo, porque a mudança já está ativa. O que vale fazer nesta semana:
- Listar quais automações dependem de cada service token e quem responde por elas. Quando o e-mail de vazamento chegar, alguém precisa saber em minutos quais serviços vão quebrar e onde o segredo novo deve entrar.
- Conferir se os destinatários de e-mail da conta Cloudflare são lidos de fato. O aviso vai para os administradores; caixa compartilhada sem dono não serve.
- Ter a rotação ensaiada: onde o segredo está guardado (secrets do CI, cofre, variáveis do Worker) e como atualizar todos os lugares de uma vez, já que não haverá período em que os dois segredos valem.
- Procurar segredos já expostos em repositórios próprios. Segredos criados a partir de 26 de agosto de 2026 seguem o formato
cfast_+ 40 caracteres alfanuméricos + 8 hexadecimais de verificação, e a Cloudflare publicou a expressão regularcfast_[A-Za-z0-9]{40}[a-f0-9]{8}para ferramentas de varredura com regras próprias.
Apagar o segredo do repositório não substitui a rotação. A própria documentação lembra que ele pode já ter sido copiado.
O que ainda não está claro
O formato com prefixo cfast_ vale só para segredos criados desde 26 de agosto. Os antigos, em 64 caracteres hexadecimais, continuam funcionando e não precisam ser trocados. A Cloudflare diz que a expressão regular não cobre esse formato antigo, mas não diz se o GitHub consegue detectá-los; como um hexadecimal sem prefixo é difícil de distinguir de outros valores, a hipótese mais segura é que tokens antigos vazados continuem ativos. Para quem tem tokens criados antes dessa data, rodar uma rotação planejada agora (com período de transição, enquanto ele ainda é permitido) traz o token para o formato detectável.
O anúncio também fala só de repositórios públicos. Não há menção a repositórios privados com secret scanning ativo nem a outros parceiros de varredura além do GitHub.
Se a sua empresa está avaliando algo parecido, me chama no LinkedIn ou no WhatsApp.
