El 11 de noviembre de 2026, Cloudflare anunció que el secret scanning de GitHub ahora reconoce los secretos de service tokens de Cloudflare Access expuestos en repositorios públicos. GitHub avisa a Cloudflare, Access desactiva el token afectado y envía un correo a los administradores de la cuenta. Antes, contener la filtración dependía de que alguien la notara y cambiara el secreto.
Un service token es la credencial que Access usa para máquinas: un par de Client ID y Client Secret que pipelines de CI, scripts, crons y servicios envían en las cabeceras para pasar por una aplicación protegida sin que una persona inicie sesión.
Qué cambia en la práctica
Dos cosas, y la segunda pesa más en la operación.
La primera es la desactivación automática. Cloudflare no pregunta antes: el token deja de autenticar en cuanto llega el reporte. Cualquier integración que dependa de él empieza a recibir el bloqueo de Access.
La segunda es la regla de recuperación. Un token marcado como filtrado solo vuelve a funcionar después de rotar el secreto, y esa rotación no admite periodo de transición. En la rotación normal de Access se puede mantener el secreto anterior válido durante un tiempo mientras se actualizan los servicios; en el token filtrado, el secreto anterior se descarta en el acto. Por API, intentar reactivar el token antes de la rotación devuelve 409, y pedir una fecha futura en previous_client_secret_expires_at devuelve 400. La rotación tampoco reactiva el token por sí sola: hay que volver a encenderlo después de distribuir el secreto nuevo. El Client ID no cambia.
Para auditoría, la API ahora devuelve leak_reported_at, leak_reporter y leak_report_url, con cuándo y dónde se encontró la filtración. La rotación borra esos campos, así que el historial queda en los registros de actividad administrativa.
Quién debe revisarlo
Equipos que usan Access para proteger paneles internos, APIs de staging o herramientas administrativas y autentican automatizaciones con service token. El riesgo concreto está en un repositorio público: un proyecto open source con workflow de despliegue, un repositorio de ejemplo publicado por error, un fork público de código interno.
Quien nunca expuso un secreto no nota diferencia. Quien lo expuso gana una protección que antes no tenía, pero también una caída del servicio sin aviso previo, en el momento en que GitHub encuentre el secreto, sea cual sea la hora.
Qué hacer ahora
No hay plazo, porque el cambio ya está activo. Lo que conviene hacer esta semana:
- Listar qué automatizaciones dependen de cada service token y quién responde por ellas. Cuando llegue el correo de filtración, alguien tiene que saber en minutos qué servicios van a fallar y dónde debe ir el secreto nuevo.
- Comprobar que los destinatarios de correo de la cuenta de Cloudflare se leen de verdad. El aviso va a los administradores; un buzón compartido sin responsable no sirve.
- Tener la rotación ensayada: dónde se guarda el secreto (secrets del CI, bóveda, variables del Worker) y cómo actualizar todos los lugares a la vez, ya que no habrá un periodo en el que valgan los dos secretos.
- Buscar secretos ya expuestos en repositorios propios. Los secretos creados desde el 26 de agosto de 2026 siguen el formato
cfast_+ 40 caracteres alfanuméricos + 8 hexadecimales de verificación, y Cloudflare publicó la expresión regularcfast_[A-Za-z0-9]{40}[a-f0-9]{8}para herramientas de escaneo con reglas propias.
Borrar el secreto del repositorio no sustituye la rotación. La propia documentación recuerda que puede haber sido copiado.
Lo que todavía no está claro
El formato con prefijo cfast_ solo aplica a secretos creados desde el 26 de agosto. Los antiguos, de 64 caracteres hexadecimales, siguen funcionando y no necesitan rotación. Cloudflare dice que la expresión regular no cubre ese formato antiguo, pero no aclara si GitHub puede detectarlos; como una cadena hexadecimal sin prefijo es difícil de distinguir de otros valores, lo más prudente es asumir que los tokens antiguos filtrados siguen activos. Para quien tenga tokens creados antes de esa fecha, hacer ahora una rotación planificada (con periodo de transición, mientras todavía se permite) lleva el token al formato detectable.
El anuncio también habla solo de repositorios públicos. No menciona repositorios privados con secret scanning activo ni otros socios de escaneo además de GitHub.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
