Ataque a paquetes Laravel-Lang compromete 700 versiones e instala ladrón de credenciales en entornos PHP
En la madrugada del 22 de mayo, un agente con acceso organizacional a GitHub reescribió 502 etiquetas históricas de cuatro paquetes PHP, inyectando un backdoor que exfiltra credenciales de cloud, tokens CI/CD y secretos de Kubernetes sin alertas visibles.
502 etiquetas reescritas en menos de una hora
En la madrugada del 22 de mayo de 2026, entre las 22:32 y las 23:24 UTC, un agente con acceso de escritura a la organización Laravel-Lang en GitHub reescribió las 502 etiquetas históricas de cuatro paquetes PHP mantenidos por la comunidad: laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes y laravel-lang/actions. El incidente fue divulgado públicamente por las firmas Socket y Aikido Security el 23 de mayo, con un issue abierto en el repositorio oficial del proyecto confirmando el compromiso en la misma fecha.
Estos paquetes no forman parte del framework Laravel oficial. Son bibliotecas de localización de terceros, ampliamente utilizadas por aplicaciones Laravel para internacionalización, distribuidas por Packagist, el repositorio central de paquetes PHP. Socket contabilizó más de 700 versiones comprometidas; Aikido confirmó 233 artefactos de paquete afectados en tres de los cuatro repositorios. La cantidad varía porque Socket incluye todas las etiquetas históricas reescritas, mientras que Aikido contabiliza solo los artefactos con payload funcional verificado.
Cómo el payload se ejecuta sin alertas
El archivo malicioso src/helpers.php fue añadido a cada versión comprometida y registrado en la clave autoload.files del composer.json. Cualquier desarrollador que ejecutara composer install o composer update contra una versión comprometida cargaba el stealer automáticamente en la primera solicitud PHP de la aplicación, sin ningún aviso de seguridad o cambio de hash visible en Packagist. El código se conecta al dominio C2 flipboxstudio[.]info para descargar una segunda etapa multiplataforma, compatible con Windows, Linux y macOS.
Claves de cloud (AWS, GCP y Azure), secretos de Kubernetes y del HashiCorp Vault, tokens de pipelines CI/CD, claves SSH, archivos .env, datos de navegadores Chromium y Firefox, cofres de administradores de contraseñas y configuraciones locales de herramientas como Anthropic Claude Code figuran entre los datos objetivos del stealer. Para equipos de DevSecOps con múltiples repositorios, un solo composer update en una máquina de build puede haber expuesto toda la cadena de credenciales organizacionales en cuestión de segundos.
Los metadatos de los commits comprometidos listan al autor como "Your Name <you@example.com>", la configuración predeterminada de Git, lo que sugiere el uso de un entorno recién configurado o un intento deliberado de no dejar rastros identificables.
El vector que diferencia este ataque
El atacante no explotó ninguna vulnerabilidad en Packagist o Composer. Obtuvo acceso de escritura directo a la organización Laravel-Lang en GitHub y reemplazó versiones históricas que los desarrolladores consideran estables y auditadas. A diferencia del typosquatting clásico o de la publicación de versiones nuevas maliciosas, este ataque comprometió versiones antiguas bloqueadas en archivos composer.lock sin alterar ningún número de versión visible para el equipo de desarrollo. Pipelines de integración continua configurados para fijar versiones históricamente verificadas, precisamente para evitar actualizaciones no auditadas, se convirtieron en el principal vector de distribución del payload.
StepSecurity, que rastrea la campaña Megalodon de compromiso de pipelines de GitHub Actions activa desde el 18 de mayo de 2026, conectó este incidente a un patrón más amplio: el atacante obtiene credenciales organizacionales de GitHub y opera a escala contra todos los repositorios accesibles. El vector inicial de acceso a la organización Laravel-Lang aún no ha sido confirmado públicamente por las firmas de seguridad.
Acciones inmediatas para equipos de seguridad
Organizaciones con dependencias en los cuatro paquetes afectados deben auditar el grafo de dependencias de Composer y comparar los hashes de las versiones instaladas con los registros legítimos de Packagist. La base de datos de asesoría de GitHub publicó un comando de detección para verificar en los logs del sistema si hubo explotación. Toda credencial presente en entornos que ejecutaron las versiones comprometidas a partir del 22 de mayo debe ser tratada como potencialmente expuesta y rotacionada: como mínimo, tokens de GitHub Actions, claves de acceso a la nube y certificados SSH.
Packagist y el equipo de Laravel-Lang eliminaron las versiones maliciosas y restauraron los repositorios a partir del historial legítimo. El incidente apunta a una brecha estructural persistente en las cadenas de dependencia PHP: Composer confía, por defecto, en la integridad de los commits Git subyacentes a las etiquetas sin verificación criptográfica independiente. Proyectos con SLSA nivel 3 o firma mediante Sigstore detectarían la adulteración automáticamente; la mayoría de los flujos de trabajo PHP aún no operan en ese nivel de rastreabilidad, y la llegada del ataque a través de una organización confiable de GitHub debe cambiar este cálculo para equipos de seguridad que aún posponían la adopción.