El ataque a laravel-lang que ha puesto en jaque a miles de proyectos PHP

El 22 de mayo de 2026, alguien comprometió las credenciales de la organización laravel-lang en GitHub. Lo que siguió fue uno de los ataques de supply chain más sofisticados que ha vivido el ecosistema PHP: más de 700 versiones de paquetes de localización muy usados fueron reescritas con una backdoor de ejecución remota de código. Sin tocar ni una línea del código fuente visible.

Si tienes laravel-lang/lang, laravel-lang/attributes, laravel-lang/http-statuses o laravel-lang/actions en tu composer.json, sigue leyendo.

Qué pasó exactamente#

El ataque no modificó los archivos del repositorio principal. Eso es lo que lo hace especialmente peligroso.

Lo que hicieron fue reescribir los tags de git — los que Packagist usa para servir versiones — para que apunten a un commit malicioso distinto. El código fuente del repositorio seguía siendo el original. Pero cualquier proyecto que instalara o actualizara los paquetes afectados recibiría el commit comprometido.

Esto lo hace casi indetectable con una revisión visual del repositorio.

Los paquetes afectados:

• laravel-lang/lang — 7.800+ estrellas en GitHub
• laravel-lang/attributes
• laravel-lang/http-statuses
• laravel-lang/actions

Las versiones comprometidas cubren las ramas 12.x, 13.x, 14.x y 15.x. Los tags se publicaron en ráfaga el 22 y 23 de mayo, muchos con apenas segundos de diferencia entre sí.

Cómo funciona la backdoor#

El payload malicioso está en un archivo src/helpers.php que el atacante registró bajo autoload.files en el composer.json del tag comprometido.

{
  "autoload": {
    "files": [
      "src/helpers.php"
    ]
  }
}

La consecuencia es que este archivo se ejecuta automáticamente en cada request, sin necesidad de que el código de la aplicación lo llame explícitamente. Composer lo carga solo.

El archivo simula ser un helper de localización inofensivo, define dos funciones de aspecto normal y luego ejecuta un bloque oculto que:

1. Construye dinámicamente el dominio C2 en tiempo de ejecución para evitar detección estática
2. Exfiltra credenciales del sistema y variables de entorno
3. Acepta comandos remotos del servidor de control

El dominio C2 detectado es flipboxstudio[.]info, construido a trozos en el código para dificultar el análisis.

Cómo saber si tu proyecto está afectado#

Paso 1: comprobar si tienes alguno de los paquetes#

composer show | grep laravel-lang

Si no aparece nada, no estás afectado por este ataque.

Paso 2: revisar el composer.lock#

Si tienes alguno de los paquetes, revisa el hash del commit en tu composer.lock:

cat composer.lock | grep -A 5 "laravel-lang/lang"

Busca el campo source.reference. Si el hash no coincide con los commits del repositorio oficial en GitHub (rama principal o tags legítimos anteriores al 22 de mayo), tu instalación es sospechosa.

Paso 3: buscar el archivo malicioso#

find vendor/laravel-lang -name "helpers.php" | xargs grep -l "flipboxstudio" 2>/dev/null

Si devuelve resultados, tienes la backdoor instalada.

Paso 4: revisar tráfico saliente sospechoso#

En servidores de producción, revisa si hay peticiones a flipboxstudio[.]info en los logs del servidor o en los logs de firewall.

grep "flipboxstudio" /var/log/nginx/access.log
grep "flipboxstudio" /var/log/apache2/access.log

Qué hacer ahora#

Si no estás afectado#

Actualiza composer.lock lo antes posible para que quede fijado a versiones limpias:

composer update laravel-lang/lang laravel-lang/attributes laravel-lang/http-statuses laravel-lang/actions

Packagist eliminó rápidamente las versiones maliciosas. Una actualización ahora te asegura recibir versiones limpias.

Si prefieres no actualizar por ahora, añade las versiones comprometidas a los conflict de tu composer.json:

{
  "conflict": {
    "laravel-lang/lang": ">=12.0.0,<16.0.0"
  }
}

Esto es temporal. La solución real es actualizar.

Si estás afectado#

Esto es un incidente de seguridad activo. Estos son los pasos en orden:

1. Aislar el servidor inmediatamente si es posible. El payload ya ha podido exfiltrar credenciales.

2. Rotar todas las credenciales que hayan podido estar expuestas:

• Variables de entorno (.env)
• Claves de API
• Contraseñas de base de datos
• Tokens de acceso a servicios externos

3. Reinstalar dependencias limpias:

rm -rf vendor/
composer install --no-dev

4. Revisar logs en busca de exfiltración:

# Logs de acceso con peticiones POST salientes sospechosas
grep "POST" /var/log/nginx/access.log | grep -v "tu-dominio.com"

5. Notificar al equipo y documentar el incidente. Si manejas datos de terceros, puede haber obligación legal de notificación según RGPD.

Por qué este ataque es especialmente preocupante#

La mayoría de los ataques de supply chain que hemos visto modifican el código fuente del repositorio. Este no. Al reescribir solo los tags de git, el ataque es invisible para:

• Revisiones de código en GitHub
• Herramientas de análisis estático que lean el repositorio fuente
• Desarrolladores que inspeccionan el código del proyecto

La única forma de detectarlo es comparar el hash del commit instalado con el hash del commit real del repositorio. Algo que casi nadie hace de forma rutinaria.

Esto eleva el nivel de sofisticación del ataque y plantea una pregunta importante: ¿con qué frecuencia revisas los hashes de tus dependencias?

Cómo proteger tu stack PHP de este tipo de ataques#

Fijar versiones en producción#

El composer.lock es tu primera línea de defensa. Nunca hagas composer update directamente en producción. Actualiza en local, revisa los cambios en el lock y despliega el lock verificado.

# En local: actualiza y revisa los diffs del lock
composer update
git diff composer.lock
 
# En producción: instala SOLO lo que dice el lock
composer install --no-dev

Usar composer audit regularmente#

composer audit

Este comando comprueba tus dependencias contra la base de datos de vulnerabilidades conocidas de Packagist. Añádelo a tu pipeline de CI.

Verificar integridad de paquetes#

Packagist incluye hashes SHA-256 para cada versión. Puedes verificarlos manualmente:

composer show --format=json laravel-lang/lang | grep source

Alertas de seguridad en el repositorio#

Si usas GitHub, activa el Dependabot y las security alerts para recibir notificaciones automáticas cuando una dependencia quede comprometida.

Monitorizar tráfico saliente del servidor#

Un servidor de producción no debería hacer peticiones salientes a dominios desconocidos. Configura un allowlist de dominios externos permitidos y alerta sobre cualquier petición fuera de él.

Errores comunes ante este tipo de incidentes#

Asumir que "solo es un paquete de localización". laravel-lang/lang tiene más de 7.800 estrellas y está en miles de proyectos. Los paquetes de utilidad son un objetivo prioritario precisamente por eso: mucho volumen, poca vigilancia.

Actualizar sin revisar el diff del lock. composer update aplica el parche, pero si no lees los cambios en el composer.lock nunca detectarás que algo fue comprometido.

Rotar solo las credenciales "importantes". En un ataque de exfiltración de entorno, todo lo que esté en el .env es potencialmente comprometido. Todo. No solo la base de datos principal.

No revisar si hay otras versiones del mismo paquete en el monorepo. En proyectos con múltiples servicios, un paquete comprometido en un servicio puede no estar en otro. Revisa todos.

Considerar cerrado el incidente tras eliminar el paquete. Si la backdoor estuvo activa durante horas o días, el daño ya pudo producirse. El cierre real es rotar credenciales, auditar logs y confirmar que no hubo movimiento lateral.

Conclusión#

El ataque a laravel-lang no es el primero de su tipo y no será el último. La supply chain de software es uno de los vectores de ataque más efectivos porque explota la confianza implícita que depositamos en las dependencias de nuestros proyectos.

La respuesta no es dejar de usar dependencias — es gestionarlas mejor.

Fijar versiones en el composer.lock, ejecutar composer audit en el pipeline, monitorizar tráfico saliente y rotar credenciales ante cualquier sospecha son prácticas que deberían ser estándar en cualquier proyecto PHP en producción.

Si no las tienes implementadas, este incidente es el momento para empezar.

Fuentes#

• Socket Research Team: análisis técnico del ataque a laravel-lang (mayo 2026)
• Aikido Security: detección inicial y análisis del payload
• The Hacker News: cobertura del incidente (22 mayo 2026)
• Packagist: respuesta oficial y eliminación de versiones comprometidas