Aviso sobre la cadena de suministro de Laravel Lang

Ataque a la cadena de suministro de Laravel-Lang: más de 700 versiones históricas de Packagist comprometidas

Actualización - 25 de mayo de 2026: Actualizamos esta publicación para incluir nuevos hallazgos de la investigación en curso. La actualización aclara el mecanismo del compromiso, sustituye las referencias anteriores a un flujo de publicación basado en bifurcaciones y agrega orientación para los usuarios de Composer/Packagist sobre cómo determinar si un proyecto se vio afectado. Como los números de las versiones afectadas se reasignaron posteriormente a código legítimo, es posible que los números de versión por sí solos no basten para confirmar el impacto. Los clientes de Snyk deben consultar la sección «Detección del ataque a la cadena de suministro de Laravel Lang con Snyk» para obtener orientación actualizada sobre análisis, clasificación y corrección.

Resumen

El 22 y el 23 de mayo de 2026, un atacante volvió a publicar cientos de versiones maliciosas bajo etiquetas de versiones históricas de cuatro bibliotecas de localización de Laravel mantenidas por la comunidad y publicadas en Packagist en el espacio de nombres laravel-lang.

Se conectó un archivo helpers.php inyectado a la entrada autoload.files de Composer, lo que hizo que se ejecutara con cada solicitud de PHP en cuanto se instalaba el paquete. Ese mecanismo se conecta a flipboxstudio[.]info, descarga una segunda etapa multiplataforma y ejecuta un programa que roba credenciales y extrae claves de la nube, secretos de Kubernetes y Vault, tokens de CI/CD, material de SSH, archivos de entorno, datos del navegador, bóvedas de administradores de contraseñas, billeteras de criptomonedas y tokens de mensajería.

Todo entorno que haya incorporado una de las versiones afectadas de la biblioteca de localización de Laravel debe considerarse comprometido hasta que se demuestre lo contrario.

Acerca del componente afectado

Los paquetes afectados están en el espacio de nombres laravel-lang/* de Packagist y GitHub.

La comunidad de Laravel los usa ampliamente para distribuir cadenas de traducción, mensajes de validación, descripciones de códigos de estado HTTP y otros recursos localizados en más de setenta idiomas.

El equipo principal de Laravel no los mantiene y no forman parte del framework oficial de Laravel, aunque se instalan en el directorio habitual de las aplicaciones Laravel y suelen aparecer como dependencias transitivas de otras herramientas de localización. Como los paquetes se incorporan mediante Composer y se registran en composer.json, la aplicación carga y ejecuta automáticamente cualquier código malicioso que incluyan.

Paquetes afectados

Todas las versiones publicadas de los siguientes cuatro paquetes se consideraron comprometidas. Packagist retiró temporalmente los paquetes de la lista, pero ya los volvió a publicar después de corregir el problema.

Los primeros cálculos de los investigadores situaban en unas 233 las versiones envenenadas, pero la cifra aumentó mientras el atacante seguía publicando etiquetas. Los informes actuales indican que hay aproximadamente 700 versiones históricas afectadas en los cuatro paquetes.

Cronología conocida

Cómo ocurrió el compromiso

El atacante obtuvo acceso a los repositorios comprometidos mediante un token de acceso personal (PAT) de GitHub filtrado, que se presume relacionado con una filtración de datos reciente de GitHub. Con ese acceso, reemplazó muchas o todas las etiquetas de versiones de cuatro repositorios laravel-lang/ por versiones fraudulentas que apuntaban a sus propios commits con malware. Los demás repositorios legítimos, incluidos todos los commits anteriores, permanecieron intactos durante todo el compromiso.

Una vez que se agregó una etiqueta maliciosa, cualquier instalación nueva de Composer que resolviera una de las versiones afectadas descargaba el código del commit fraudulento. La carga maliciosa estaba oculta en un archivo nuevo, src/helpers.php, y se registró en composer.json dentro de autoload.files. El cargador automático de Composer incluye sin condiciones todos los archivos de esa lista, por lo que el código malicioso se ejecuta al comienzo del ciclo de vida de cada solicitud de PHP, incluso durante la ejecución de comandos, procesos en segundo plano y controladores de colas.

Comportamiento de la carga maliciosa

La primera etapa, integrada en src/helpers.php, es intencionalmente ligera. Escribe un marcador de infección en un directorio temporal específico del host para infectarlo una sola vez y luego descarga una segunda etapa desde https://flipboxstudio\[.\]info/payload y la ejecuta en segundo plano. El mecanismo de ejecución detecta la plataforma y funciona en Linux, macOS y Windows.

La segunda etapa roba credenciales y secretos. Una vez instalada, recorre una larga lista de fuentes en busca de información valiosa:

• Credenciales y tokens de proveedores de nube (por ejemplo, archivos de perfil de AWS, GCP y Azure).

• Archivos kubeconfig de Kubernetes, tokens de HashiCorp Vault y secretos de CI/CD presentes en el entorno.

• Claves privadas de SSH y datos de known_hosts.

• Archivos .env de aplicaciones con credenciales de bases de datos, API y servicios.

• Datos del navegador, incluidas cookies, historial e inicios de sesión guardados.

• Bóvedas de administradores de contraseñas a las que se puede acceder desde el disco.

• Archivos de billeteras de criptomonedas y almacenes de claves.

• Tokens de mensajería y colaboración de herramientas como Slack, Discord y Telegram.

Los datos recopilados se cifran y se envían a https://flipboxstudio\[.\]info/exfil. Después de la exfiltración, el programa que roba datos intenta eliminar los archivos que dejó para dificultar la recuperación forense. En hosts Windows, la cadena incluye un script de ejecución .vbs y un archivo ejecutable llamado DebugChromium.exe, detectado en sistemas infectados.

Indicadores de compromiso

Usa los siguientes indicadores para buscar sistemas afectados. El dominio C2 y las URL deben considerarse maliciosos.

Orientación para la detección y el análisis

Considera sospechoso cualquier host que haya resuelto alguno de los cuatro paquetes entre el 22 y el 23 de mayo de 2026, aunque se haya reconstruido desde entonces. La señal más rápida está en el nivel de las dependencias: revisa composer.lock y composer.json en todos tus proyectos para buscar referencias a los paquetes laravel-lang mencionados arriba. A continuación, encontrarás algunas comprobaciones prácticas.

• Busca laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes o laravel-lang/actions en los artefactos de compilación e implementación, y registra la versión y el hash de integridad anotados en composer.lock.

• Revisa las copias instaladas en vendor/laravel-lang/*/ para ver si contienen src/helpers.php, y comprueba si composer.json lo declara en la clave files de autoload. No hay razón legítima para que un paquete de localización incluya un archivo helpers que se cargue automáticamente en cada solicitud.

• En hosts Linux y macOS, busca un directorio .laravel_locale en $TMPDIR y /tmp: cualquier contenido allí indica que se ejecutó el código. Guárdalo antes de limpiarlo para realizar un análisis forense.

• En hosts Windows, busca en el directorio temporal del usuario (normalmente %TEMP%) una carpeta .laravel_locale que contenga archivos dropper .vbs con nombres de ocho caracteres hexadecimales aleatorios. Además, busca en el sistema de archivos cualquier ejecutable llamado DebugChromium.exe.

• Revisa los registros del proxy de salida, DNS y firewall en busca de consultas o conexiones a flipboxstudio[.]info. Bloquea el dominio en el resolver y en el perímetro.

• Busca ejecuciones inesperadas de procesos PHP o CScript en segundo plano en los registros de EDR y de endpoints. En Linux y macOS, también revisa las lecturas de /var/run/secrets/ y `/proc/[pid]/environ`, a las que accede el programa que roba credenciales mientras recopila secretos.

Aclaración sobre la orientación para ignorar el problema

Debido a la naturaleza del compromiso y a la corrección posterior, es posible que los sistemas de Snyk solo reconozcan actualmente la versión más reciente instalada. Los clientes deben realizar un análisis histórico para confirmar si el paquete malicioso se instaló alguna vez entre el 22 y el 23 de mayo de 2026, y no basarse únicamente en el estado de la versión más reciente. Considera afectado cualquier host que haya instalado uno de los cuatro paquetes durante el periodo del compromiso hasta que se demuestre lo contrario.

Detección del ataque a la cadena de suministro de Laravel Lang con Snyk

Para los usuarios de Snyk, el producto Open Source y la Snyk Vulnerability Database ya señalan todas las versiones de los paquetes afectados. Durante el compromiso, se publicaron etiquetas maliciosas con números de versión legítimos. Cuando se recuperaron los proyectos, esas mismas etiquetas legítimas se desvincularon de los commits maliciosos, por lo que los números de versión por sí solos no permiten determinar si un paquete instalado estuvo o está afectado por este compromiso. (Consulta las secciones «Indicadores de compromiso» y «Orientación para la detección y el análisis» anteriores). Analiza de inmediato todos los repositorios basados en Composer y presta especial atención a los monorepositorios y al código de plataformas compartidas.

Si, después de revisar tu composer.lock, la compilación, el momento de la instalación y los indicadores de compromiso disponibles, determinas que tu proyecto no se vio afectado, puedes usar la función Ignorar de Snyk para que este problema deje de aparecer en futuros análisis. Consulta la documentación de Snyk sobre cómo ignorar problemas para obtener más información.

Snyk CLI detecta automáticamente tu archivo de bloqueo de Composer y encuentra paquetes vulnerables y maliciosos:

1snyk test

Snyk CLI es gratis. Si aún no lo tienes instalado, sigue las guías de usuario de Snyk CLI.

Si conectas Snyk a tus repositorios de Git, Snyk puede abrir automáticamente PR para actualizar los paquetes vulnerables de tu archivo composer.lock a versiones seguras.

Para los clientes de Snyk Enterprise, ya volvimos a ejecutar los análisis en su nombre. Puedes consultar Analytics → Reports → Zero-Day → Active Security Incident Assessment para Laravel-Lang Supply Chain Attack.

Mitigación y corrección

Si se confirma que los paquetes afectados se instalaron, asume que se exfiltró todo lo que el proceso de PHP podía leer durante la ejecución y actúa en consecuencia. El orden siguiente refleja la secuencia habitual de respuesta a incidentes.

• Pon en cuarentena los hosts afectados. Retira de servicio todos los servicios expuestos a Internet que hayan ejecutado las versiones afectadas, toma imágenes de disco para el análisis forense y reconstruye los sistemas a partir de una imagen confiable, en lugar de limpiarlos sin reinstalarlos.

• Asegúrate de no instalar el conjunto de paquetes afectados de Laravel Lang (ni probablemente otros paquetes de este mantenedor/equipo). Como el atacante reescribió etiquetas históricas de Git, no se puede confiar en ningún número de versión publicado por sí solo; una versión anterior ahora podría apuntar al commit malicioso.

• Rota todas las credenciales a las que el proceso de PHP pudo haber tenido acceso. Esto incluye claves de proveedores de nube, contraseñas de bases de datos, credenciales de colas y caché, tokens de API de terceros, secretos de clientes OAuth, claves SSH, claves de firma, tokens de Vault y Kubernetes, y cualquier secreto inyectado por CI/CD.

• Audita las cuentas de las personas que comparten las mismas estaciones de trabajo. También podrían haberse robado los inicios de sesión guardados en navegadores, las bóvedas de administradores de contraseñas, las billeteras de criptomonedas y los tokens de Slack o Discord. Cambia las contraseñas guardadas en los navegadores, invalida las sesiones y revisa los métodos de MFA registrados.

• Bloquea el dominio C2. Agrega flipboxstudio[.]info a las listas de bloqueo de DNS sinkhole, proxies y detecciones de EDR. Incluso un solo intento de resolución es una señal clara de exposición.

• Revisa los permisos de SCM y de los registros de paquetes, ya que laravel-lang/* pudo haberse instalado de forma transitiva. Confirma que tus organizaciones de GitHub, GitLab y Packagist tengan MFA respaldada por hardware, tokens con permisos acotados y un proceso de revisión para crear etiquetas y publicar paquetes.

Lecciones aprendidas y defensa en profundidad

Este incidente es un recordatorio útil de que el límite de confianza de un paquete no es el repositorio de origen en la pestaña del navegador. Es la cadena de sistemas que determina qué commit se convierte en un artefacto publicado. Algunas prácticas reducen el alcance de ataques similares:

• Verifica la integridad durante la instalación. Composer registra hashes del contenido de los paquetes en composer.lock; usa --no-cache y la verificación de integridad en CI para detectar manipulaciones.

• Implementa controles de tráfico saliente en los entornos de compilación. Los ejecutores de CI y los contenedores de producción no deberían poder acceder a dominios arbitrarios. En este caso, una lista de permitidos habría impedido la descarga de la segunda etapa.

• Usa secretos de corta duración y con permisos acotados. Las credenciales de larga duración en archivos .env amplifican los daños de cualquier robo de secretos dentro del proceso.

La declaración oficial del proyecto afectado, que incluye detalles sobre GitHub, está disponible aquí: Declaración oficial sobre el incidente.

También recomendamos revisar tus prácticas de seguridad y aprender cómo proteger el framework PHP Laravel en un artículo anterior que publicamos, así como consultar el recurso de Snyk Learn sobre prácticas de desarrollo seguro en PHP.

Estado de Snyk

Los productos y la infraestructura de Snyk no se ven afectados por este incidente. Ya se publicaron avisos de Snyk sobre los paquetes afectados y se está actualizando Snyk Vulnerability Database a medida que se confirman nuevos rangos de versiones. Snyk sigue monitoreando la situación y actualizará este aviso cuando surjan más detalles.