Packagist está dando la voz de alarma para los desarrolladores de PHP de todas partes. Un fallo en Composer, el gestor de dependencias de PHP ampliamente utilizado, causó brevemente que los tokens de autenticación de GitHub se filtraran en los registros de CI visibles públicamente, lo que generó preocupaciones urgentes sobre la exposición de credenciales en miles de proyectos de software activos en todo el mundo.

El problema comenzó cuando GitHub empezó a implementar discretamente un nuevo formato de token para su servicio de GitHub Actions a finales de abril de 2026. El formato actualizado incluía un guion en la cadena del token, algo que el código de validación interna de Composer nunca estuvo diseñado para manejar.

Cuando Composer encontraba uno de estos tokens de nuevo estilo, rechazaba el token directamente e imprimía el valor completo del mismo en el registro de Actions como parte de un mensaje de error estándar, donde cualquier persona con acceso al registro podría leerlo potencialmente sin ningún esfuerzo técnico especial.

Los investigadores de Socket.dev estuvieron entre quienes alertaron sobre el alcance total y la gravedad de este problema para la comunidad de desarrolladores en general. El hallazgo dejó claro que no se trataba de un caso aislado menor o de una vulnerabilidad teórica, sino de un riesgo real capaz de afectar a cualquier proyecto de PHP que ejecute Composer dentro de un flujo de trabajo de GitHub Actions.

La exposición se deriva de cómo operan en la práctica muchos flujos de trabajo de configuración populares cada día. Cuando los desarrolladores utilizan un ayudante común de GitHub Actions como shivammathur/setup-php, este registra automáticamente el GITHUB_TOKEN en la configuración de autenticación global de Composer.

Si ese token coincidía con el nuevo formato durante el periodo de despliegue, Composer lo rechazaría y expondría la credencial completa en el registro sin ninguna advertencia ni señal visible para el desarrollador que configuró originalmente ese flujo de trabajo.

Packagist insta a actualizar Composer inmediatamente

Desde entonces, GitHub ha revertido el nuevo formato de token, lo que reduce la posibilidad inmediata de que ocurran nuevas filtraciones en este momento. Sin embargo, el cofundador de Packagist, Nils Adermann, dejó claro que la reversión no deshace lo que ya ha sucedido, y los equipos aún deben actualizar Composer y auditar minuciosamente sus registros recientes en busca de cualquier signo de exposición de credenciales antes de que GitHub intente otro despliegue del formato modificado en las próximas semanas.

Tres versiones de Composer contienen ahora el parche oficial para este problema. Los desarrolladores que utilicen configuraciones modernas deben actualizar a Composer 2.9.8 o a la versión de soporte a largo plazo 2.2.28 LTS sin demora.

Los usuarios heredados que aún estén en ramas más antiguas pueden actualizar a Composer 1.10.28, que también incluye la misma corrección, aunque Packagist recomienda pasar a la línea Composer 2.x siempre que sea posible para obtener una cobertura de seguridad a largo plazo más sólida.

La corrección funciona eliminando por completo el valor del token rechazado de la salida de error de Composer y también flexibiliza la lógica de validación para que la herramienta ya no verifique los tokens basándose en un patrón de caracteres predefinido.

Esto hace que Composer sea mucho más resistente a futuros cambios de formato de tokens de cualquier plataforma. La conclusión general es clara: las herramientas deben tratar los tokens de acceso como cadenas opacas y nunca hacer suposiciones sobre su longitud, estructura o conjunto de caracteres, especialmente cuando las plataformas están evolucionando activamente esos formatos.

Qué deben hacer los equipos ahora mismo

El propio Packagist.org no se vio afectado por este problema, ya que el registro público no utiliza tokens de instalación de aplicaciones de GitHub ni ejecuta Composer contra ellos directamente. Private Packagist también ha aplicado la corrección y ha auditado completamente sus propios registros de actualización, sin encontrar ninguna exposición de tokens en ninguna actividad registrada.

Pero el riesgo sigue siendo real para cualquier proyecto que ejecute Composer dentro de GitHub Actions, especialmente donde las acciones de configuración registran automáticamente el GITHUB_TOKEN en la capa de autenticación de Composer.

Los equipos deben comenzar actualizando Composer a una de las tres versiones parcheadas inmediatamente. Luego, deben revisar los registros recientes de GitHub Actions en busca de cualquier ejecución fallida de Composer que haya podido imprimir accidentalmente el valor de un token en la salida. Siempre que sea posible, esas entradas de registro deben eliminarse para evitar una mayor exposición.

Los tokens de los ejecutores alojados en GitHub suelen expirar cuando termina la tarea o después de seis horas, pero los tokens en ejecutores autoalojados pueden permanecer válidos hasta 24 horas, y cualquier token que se crea que haya sido expuesto debe tratarse como comprometido y rotarse de inmediato.