Los tokens de GitHub Apps requieren una revisión de compatibilidad: GitHub confirmó el 2 de octubre de 2026 que completó el despliegue de su nuevo formato para los tokens de instalación. Las integraciones deben aceptar credenciales más largas, tratarlas como cadenas opacas y comprobar que sus sistemas no las recorten ni las expongan en registros. El encabezado temporal que permite elegir el formato dejará de respetarse el 30 de noviembre de 2026. Para un equipo que automatiza repositorios o despliegues, la tarea inmediata es probar el recorrido completo de la credencial y retirar ese encabezado una vez validados ambos formatos.
¿Tienes un proyecto en mente o requieres consultoría en software?
Habla directamente con un especialista de GitCoders vía WhatsApp y recibe orientación arquitectónica personalizada para tu negocio.
Qué cambió en los tokens de instalación
Según el anuncio oficial de GitHub del 2 de octubre, el despliegue comenzó el 27 de abril y ya terminó. Los tokens recién emitidos usan por defecto el formato stateless ghs_APPID_JWT. Mantienen el prefijo ghs_, pero pasan de unos 40 caracteres a aproximadamente 520. Esa cifra orienta la revisión; no debe convertirse en una validación de longitud exacta.
GitHub atribuye al cambio una emisión y validación más rápidas y mayor fiabilidad de su API. Esa es una explicación del proveedor, no una medición independiente del rendimiento de cada integración.
Qué sigue igual
El mismo anuncio señala que se mantienen los permisos, el alcance por repositorios, la expiración de una hora y el endpoint REST utilizado para emitir tokens de instalación. Las credenciales emitidas antes del cambio siguen funcionando hasta expirar. El formato nuevo no concede permisos adicionales por sí mismo.
La documentación de autenticación de GitHub Apps explica cómo solicitar el token y limitar sus permisos y repositorios. Mantener un alcance reducido sigue siendo una decisión de configuración de la integración.
A quién afecta y cuál es el alcance internacional
El anuncio del encabezado temporal delimita el cambio a los tokens de instalación de GitHub Apps para comunicación entre servidores, incluido GITHUB_TOKEN de Actions, y contempla GitHub Enterprise Cloud y sus entornos con residencia de datos. GitHub Enterprise Server queda fuera del alcance descrito.
La revisión resulta pertinente para equipos de cualquier país que utilicen esos entornos. No es una exigencia legal local ni un cambio general de todos los tipos de credenciales de GitHub. Antes de actuar, identifica si tu integración utiliza un token de instalación, un token personal u otro mecanismo de autenticación.
Qué revisar en una integración existente
Recomendación práctica: prueba una integración representativa en un entorno controlado y recorre el camino desde la emisión del token hasta la solicitud autenticada. La lista siguiente traduce los puntos del anuncio a tareas de revisión; no supone que todos los sistemas tengan un fallo.
Validación y almacenamiento
- Busca comprobaciones que exijan exactamente 40 caracteres o patrones escritos para el formato anterior.
- Revisa columnas de bases de datos, gestores de secretos y límites configurados para variables de entorno. Evita un límite ajustado a la longitud aproximada actual.
- Trata el token como una cadena opaca: no hagas depender tu lógica de negocio de su contenido interno.
Transporte y ocultación de secretos
- Comprueba que proxies, pasarelas y componentes intermedios acepten el encabezado
Authorizationcompleto. - Revisa las reglas que ocultan credenciales en registros: un patrón antiguo podría dejar de reconocer el token nuevo.
- Verifica el resultado con datos controlados sin imprimir una credencial real para diagnosticar el problema.
La guía independiente de OWASP sobre gestión de secretos respalda prácticas generales como el mínimo privilegio, la gestión del ciclo de vida y la automatización del manejo de credenciales. OWASP no confirma este lanzamiento de GitHub; aporta el contexto de seguridad para las recomendaciones.
Cómo preparar el retiro del encabezado temporal
El encabezado X-GitHub-Stateless-S2S-Token se introdujo para probar ambos formatos al solicitar un token mediante POST /app/installations/:installation_id/access_tokens. La referencia oficial de mayo describe enabled para solicitar el formato stateless y disabled para solicitar el clásico.
La comunicación más reciente fija su retiro para el 30 de noviembre de 2026: después de esa fecha GitHub dejará de respetarlo y todas las aplicaciones elegibles recibirán tokens stateless. GitHub pide validar ambos formatos y retirar el encabezado del código de producción antes de esa fecha.
- Identifica quién emite y consume el token, incluidos servicios intermedios.
- Comprueba ambos formatos con las opciones temporales documentadas.
- Verifica almacenamiento, transporte, autenticación y ocultación en registros.
- Retira el encabezado cuando las pruebas sean satisfactorias y observa el comportamiento de la integración.
La documentación general todavía contiene referencias al despliegue iniciado en abril. Para la fecha de retiro, utiliza el anuncio del 2 de octubre, que aporta el calendario más reciente.
Oportunidades y precauciones para los equipos
Análisis: revisar este cambio permite detectar dependencias frágiles de un formato de credencial y reducir fallos evitables en automatizaciones. No exige rehacer una integración que ya trata los tokens como cadenas opacas y admite su longitud.
La prueba debe cubrir un resultado útil, como leer un repositorio con los permisos previstos, además de confirmar que el token se almacenó completo. Tampoco conviene ampliar permisos para resolver un error que realmente proviene de truncamiento o validación.
Esta revisión complementa otras tareas de automatización: GitCoders explica cómo separar preparación y aprobación con tokens stage only de npm y cómo configurar reglas de cobertura de código mediante la API de GitHub. Son controles diferentes; ninguno sustituye comprobar la compatibilidad de las credenciales.
Preguntas frecuentes
¿Todos los tokens de GitHub ahora tienen unas 520 letras?
No. El anuncio trata los tokens de instalación de GitHub Apps. La longitud es aproximada y no debe extrapolarse a tokens personales ni usarse como comprobación exacta.
¿Cambian los permisos o la duración del token?
GitHub indica que no: conserva los permisos, el alcance por repositorios y la expiración de una hora de estos tokens.
¿Puedo mantener el encabezado temporal después de noviembre?
GitHub anunció que dejará de respetarlo el 30 de noviembre de 2026. El plan recomendado es probar ambos formatos y retirarlo antes de esa fecha.
¿Debo aplicar este calendario a GitHub Enterprise Server?
No con base en estos anuncios. La documentación de alcance excluye Enterprise Server. Revisa las notas de la versión de tu entorno antes de trasladar cambios de Enterprise Cloud.
Fuentes y fecha de verificación
- GitHub Changelog: despliegue completado, publicado el 2 de octubre de 2026.
- GitHub Changelog: encabezado temporal, publicado el 15 de mayo de 2026; notas editoriales del 26 de mayo y 10 de junio.
- GitHub Docs: generación de tokens de instalación; documentación técnica consultada.
- OWASP: Secrets Management Cheat Sheet; referencia independiente para recomendaciones generales.
Verificado el 3 de octubre de 2026 a las 11:09, America/Lima. Los anuncios describen un cambio de producto, no una norma ni una garantía de rendimiento. Confirma el calendario y el alcance en las fuentes enlazadas antes de implementar cambios.
¿Tu sitio web carga lento o no genera los clientes esperados?
Solicita tu Auditoría Web 360° Gratuita. Evaluamos velocidad Core Web Vitals, optimización SEO on-page, posicionamiento local GEO y experiencia de usuario.
Comentarios