Los tokens de instalación de GitHub App son ahora JWT de 520 caracteres

GitHub ha terminado de cambiar todos los tokens de instalación de GitHub App recién creados a un nuevo formato "sin estado" (stateless), según anunció la empresa en su registro de cambios el 2 de octubre de 2026. Los tokens siguen empezando por ghs_, pero ahora miden unos 520 caracteres en lugar de 40. Cualquier código que diera por hecha la longitud antigua, como un patrón de validación o una columna de base de datos, puede ahora rechazar o recortar un token que funciona.

Qué ha cambiado

Un token de instalación es la contraseña de corta duración que usa una GitHub App para actuar sobre los repositorios en los que está instalada. GitHub empezó un despliegue escalonado del nuevo formato el 27 de abril de 2026. El registro de cambios del 2 de octubre dice que ese despliegue ha terminado, así que el nuevo formato es ya el predeterminado.

El nuevo token es un JWT, siglas de JSON Web Token: una cadena firmada que lleva información dentro. Según el registro de cambios de mayo de GitHub, los dos formatos se distinguen contando puntos. Un token sin estado contiene dos puntos, mientras que el antiguo token opaco no contiene ninguno.

	Formato antiguo	Formato nuevo
Prefijo	ghs_	ghs_
Longitud	40 caracteres, fija	unos 520 caracteres, puede variar
Puntos en el token	0	2
Duración	1 hora	1 hora, sin cambios

Los permisos, el alcance por repositorio y la caducidad de una hora no cambian, según GitHub. Solo ha cambiado la forma de la cadena.

Qué lleva el token

El proyecto Kingfisher de MongoDB, un escáner que busca secretos filtrados, describió el formato en una incidencia abierta el 26 de abril. Escribe el patrón como ghs_APPID_JWT. Según la incidencia, la parte JWT contiene datos como la instalación de destino y la app, además de datos básicos de validación.

Ese JWT lo firma el emisor interno de la propia GitHub. La incidencia de Kingfisher dice que las aplicaciones cliente no deben intentar validarlo. Para tu código, el token debe seguir siendo una cadena opaca: algo que guardas y envías, nunca algo que analizas.

Kingfisher también advirtió de que su propia regla de detección para estos tokens necesitaría una actualización cuando terminara el despliegue. Los escáneres de secretos que buscan la antigua forma de 40 caracteres son uno de los primeros lugares donde se nota este cambio.

El encabezado de anulación y su fecha límite

En mayo, GitHub añadió un encabezado temporal, X-GitHub-Stateless-S2S-Token, a la petición que crea un token de instalación. Enviar enabled devuelve un token con el formato nuevo. Enviar disabled devuelve un token con el formato antiguo, incluso para apps ya migradas. Si no se envía el encabezado, se aplica el valor predeterminado.

Esa vía de escape se está cerrando. El registro de cambios del 2 de octubre dice que el encabezado quedará obsoleto el 30 de noviembre de 2026. A partir de esa fecha, los equipos que fijaron el formato antiguo para ganar tiempo perderán esa opción.

El registro de cambios de mayo de GitHub incluye GitHub Enterprise Cloud y sus regiones de residencia de datos. También menciona el GITHUB_TOKEN de Actions, el token que usan los flujos de trabajo, junto a los tokens de App de servidor a servidor.

Qué significa esto para los desarrolladores

Busca en tu código cualquier cosa que trate estos tokens como si tuvieran un tamaño fijo. La guía de GitHub señala cuatro puntos problemáticos: comprobaciones de longitud, límites de columnas de base de datos, truncado de encabezados y patrones en los logs. Cada uno puede fallar sin avisar. Una columna de 40 o 255 caracteres recortará el token, y la llamada a la API fallará con lo que parece un error de autenticación.

Después, corrige los patrones de validación. Un patrón como ghs_[A-Za-z0-9]{36} rechaza el nuevo token, porque el token es más largo y contiene puntos. El registro de cambios de mayo de GitHub sugiere ghs_[A-Za-z0-9.\-_]{36,}, que coincide con ambos formatos. Prueba tu propio patrón con una muestra inventada de cada forma en un probador de expresiones regulares, nunca con un token real.

Asegúrate de que el almacenamiento admite al menos 520 caracteres, dice GitHub. Eso incluye cachés, almacenes de secretos y variables de entorno con límite de tamaño. Si ocultas secretos en los logs, comprueba que tu ocultación sigue detectando el token más largo. Si no, parte de una credencial real podría acabar en texto plano.

Si configuraste el encabezado de anulación como disabled esta primavera, tienes hasta el 30 de noviembre para quitarlo. Prueba primero con enabled y después elimina el encabezado.