Laravel Lang: los paquetes que usaban miles de desarrolladores PHP tenían malware dentro
El 22 de mayo de 2026, a las 22:32 UTC, un atacante comprometió la infraestructura de publicación de Laravel Lang, un conjunto de paquetes PHP de localización utilizado por decenas de miles de proyectos Laravel en todo el mundo. Lo que siguió fue una cadena de suministro envenenada con una técnica que los filtros de seguridad habituales no detectan: el código fuente oficial no se tocó. Las etiquetas de versión de GitHub, sí.
🔍 ¿Dudas de un mensaje recibido?
Analiza remitentes, enlaces o archivos en tiempo real con nuestro scanner.
Qué es Laravel Lang y por qué importa
Laravel Lang no forma parte del framework Laravel oficial, pero es prácticamente indispensable en cualquier proyecto Laravel con soporte multiidioma. Sus paquetes proporcionan los mensajes de validación, los estados HTTP y los atributos de formulario ya traducidos a decenas de idiomas.
Los cuatro paquetes afectados son:
- laravel-lang/lang
- laravel-lang/http-statuses
- laravel-lang/attributes
- laravel-lang/actions
Se instalan a través de Composer, el gestor de dependencias de PHP, y en muchos proyectos se actualizan automáticamente en los pipelines de CI/CD. Eso es exactamente lo que el atacante aprovechó.
La técnica: envenenar las etiquetas de GitHub, no el código
Aquí está la clave forense del caso. El atacante no modificó ningún archivo en los repositorios oficiales de Laravel Lang. Eso habría sido detectado inmediatamente por cualquier revisión de código o comparación de hashes.
Lo que hizo fue explotar una característica de GitHub: las etiquetas de versión (tags) pueden apuntar a commits de forks externos, no solo al repositorio principal.
El flujo del ataque fue el siguiente:
- El atacante obtuvo acceso a las credenciales de la organización Laravel Lang en GitHub (probablemente a través de un token de automatización o credenciales de release comprometidas).
- Creó un fork malicioso de cada repositorio con el código infectado.
- Reescribió todas las etiquetas de versión existentes para que apuntaran a commits de su fork, en lugar de al código oficial.
- Las etiquetas se publicaron en ráfaga rápida el 22 y 23 de mayo, muchas con segundos de diferencia entre ellas, lo que indica automatización.
- Cuando un desarrollador ejecutaba
composer installocomposer update, Composer descargaba la versión indicada en elcomposer.lock— que ahora apuntaba silenciosamente al código del atacante.
Aikido Security confirmó 233 versiones comprometidas en tres repositorios. Socket elevó la cifra a aproximadamente 700 versiones históricas afectadas.
El payload: qué hacía el malware una vez dentro
El archivo infectado era src/helpers.php. Composer lo cargaba automáticamente en cada arranque de la aplicación gracias a la directiva autoload.files del composer.json — sin que el desarrollador tuviera que llamarlo explícitamente.
Este archivo actuaba como dropper: contactaba con el servidor de mando y control en flipboxstudio[.]info y descargaba el ladrón de credenciales real adaptado al sistema operativo detectado. El malware era multiplataforma: funcionaba en Linux, macOS y Windows.
Qué robaba
La lista de objetivos era exhaustiva:
- Credenciales cloud: claves AWS, service account JSON de Google Cloud, credenciales de Azure
- Secretos de infraestructura: tokens de Kubernetes, configuraciones de entornos CI/CD
- Tokens de desarrollador: tokens de GitHub, claves SSH
- Navegadores: contraseñas, cookies y sesiones almacenadas
- Carteras de criptomonedas: seeds y claves privadas
- Variables de entorno: archivos
.envde proyectos Laravel, donde habitualmente se almacenan las credenciales de base de datos y APIs
El componente Windows: DebugElevator
En sistemas Windows el dropper descargaba además un ejecutable llamado DebugElevator, diseñado específicamente para extraer las claves de cifrado App-Bound Encryption de Chrome, Brave y Edge — la protección que Google introdujo en 2024 para dificultar el robo de cookies de sesión. El nombre del atacante interno encontrado en el binario era Mero.
Línea de tiempo
| Fecha / Hora | Evento |
|---|---|
| 22/05/2026 22:32 UTC | Inicio del ataque — primera etiqueta maliciosa publicada |
| 22–23/05/2026 | ~700 etiquetas reescritas en ráfaga automatizada |
| 22/05/2026 | Aikido Security detecta el ataque y notifica a los mantenedores |
| 23/05/2026 | BleepingComputer, Socket y StepSecurity publican alertas |
| 24/05/2026 | Packagist elimina las versiones maliciosas y desindexar temporalmente los paquetes |
Estoy usando Laravel Lang. ¿Qué hago ahora?
Si tu proyecto usa alguno de los cuatro paquetes afectados y realizaste una instalación o actualización después de las 22:32 UTC del 22 de mayo de 2026, asume que el sistema estuvo expuesto.
Pasos inmediatos:
- Rotar todas las credenciales del entorno: claves AWS, tokens de GitHub, credenciales de base de datos del
.env, tokens de API, claves SSH. - Revisar conexiones de red salientes desde los servidores afectados hacia flipboxstudio[.]info — si aparece en los logs, la exfiltración fue real.
- Actualizar Composer a una versión limpia de los paquetes. Packagist ya ha eliminado las versiones maliciosas.
- Revisar el
composer.lockdel proyecto para identificar qué versión estaba instalada en la ventana de ataque. - Auditar los logs de CI/CD — si el pipeline actualizó dependencias automáticamente durante ese período, todos los secretos del entorno de build deben considerarse comprometidos.
Por qué esta técnica es especialmente peligrosa
Los ataques a la cadena de suministro son más difíciles de detectar que el phishing clásico porque el vector no es un correo fraudulento ni un enlace sospechoso — es una dependencia que el desarrollador ha instalado deliberadamente y que considera de confianza.
En este caso la técnica de reescritura de etiquetas de GitHub añade una capa adicional de invisibilidad: el repositorio oficial no tiene ningún commit malicioso. Una revisión manual del código fuente en GitHub mostraría el código limpio. El veneno estaba en el sistema de distribución, no en el código visible.
Herramientas como Aikido Security, Socket o Dependabot que monitorizan comportamientos anómalos en las dependencias — no solo el código en sí — son las que detectaron este ataque. La revisión manual habría llegado demasiado tarde.
Conclusión
El caso Laravel Lang es un recordatorio de que en la seguridad de software moderno, confiar en el código no es suficiente — hay que confiar también en la infraestructura que lo distribuye. Un paquete legítimo con años de historial puede convertirse en un vector de ataque si el sistema de publicación queda comprometido.
Si usas Composer en proyectos en producción, este es el momento de revisar qué herramientas tienes para detectar cambios inesperados en las dependencias antes de que lleguen a tu servidor.
Fuentes: Aikido Security, Socket, BleepingComputer, The Hacker News — mayo 2026.
Análisis forense: Oscar Orts · Perito Informático Judicial · ORTSLAB.ES