GitHub completó el 2 de octubre el despliegue del nuevo formato stateless para los tokens de instalación de GitHub Apps. Todos los tokens recién emitidos utilizan ahora el formato ghs_APPID_JWT y tienen alrededor de 520 caracteres, frente a los aproximadamente 40 del formato anterior, según el anuncio oficial.
Qué cambia y qué se mantiene
Los permisos, el alcance por repositorio, la expiración de una hora y el endpoint para generar installation access tokens no cambian. Los tokens ya emitidos seguirán funcionando hasta que caduquen.
La diferencia principal está en el formato y la longitud. GitHub busca acelerar emisión y validación y mejorar la fiabilidad de la API.
El riesgo está en sistemas que asumían 40 caracteres
GitHub pide revisar validaciones rígidas, columnas de base de datos, almacenes de secretos, variables de entorno, proxies y reglas de redacción de logs que puedan truncar o rechazar cadenas largas.
Una integración puede fallar aunque el endpoint y los permisos sigan siendo los mismos si algún componente intermedio limita el tamaño del token.
El header temporal desaparecerá el 30 de noviembre
El header X-GitHub-Stateless-S2S-Token, utilizado durante la transición, dejará de respetarse el 30 de noviembre de 2026. GitHub recomienda eliminarlo del código de producción una vez validado el nuevo formato.
Qué debería hacer una empresa
Conviene buscar expresiones regulares que validen el antiguo patrón, comprobar tamaños máximos en bases de datos y secretos y verificar que los logs sigan ocultando completamente el token. También es recomendable probar integraciones internas y de terceros antes de retirar el header temporal.
Este cambio se suma a otras novedades recientes de seguridad y desarrollo que hemos cubierto: el Microsoft Digital Defense Report 2026, la actualización de GitHub CodeQL, el parche crítico de GitLab, las passkeys en Microsoft Entra, la remediación automática de Cloudflare CASB y el nuevo Microsoft Defender ISOC.
Qué puede romperse si una integración asumía tokens de 40 caracteres
El riesgo principal no está en los permisos del token, que mantienen el mismo alcance y expiración de una hora, sino en sistemas que validan una longitud fija. Columnas de base de datos, expresiones regulares, proxies, filtros de secretos o herramientas de logging pueden truncar o rechazar el nuevo formato de unas 520 posiciones. GitHub recomienda tratar el token como una cadena opaca y no extraer significado de su estructura. Las empresas deberían probar generación, almacenamiento temporal, transmisión y redacción en logs antes de que el cambio llegue a todos sus flujos.
Fotografía: panumas nikhomkhai / Pexels.
