Investigadores de ciberseguridad han descubierto un grave problema de
seguridad que
permite que las APP_KEYs filtradas de Laravel se utilicen como arma para
obtener capacidades de ejecución remota de código en cientos de
aplicaciones.
«La APP_KEY de Laravel, esencial para cifrar datos confidenciales, suele
filtrarse públicamente (por ejemplo, en GitHub)»,
declaró GitGuardian.
«Si los atacantes acceden a esta clave, pueden explotar una falla de
deserialización para ejecutar código arbitrario en el servidor, poniendo en
riesgo los datos y la infraestructura».
La compañía, en
colaboración con Synacktiv, afirmó haber extraído más de 260.000 APP_KEYs de GitHub entre 2018 y el 30
de mayo de 2025, identificando más de 600 aplicaciones Laravel vulnerables en
el proceso.
APP_KEY es una clave de cifrado aleatoria de 32 bytes que se genera durante la
instalación de Laravel. Almacenada en el archivo .env de la
aplicación, se utiliza para cifrar y descifrar datos, generar cadenas
aleatorias seguras, firmar y verificar datos, y crear tokens de autenticación
únicos, lo que la convierte en un componente de seguridad crucial.
Utilizando Shodan, descubrieron 650.000 instancias de Laravel y recuperaron
las cookies de sesión correspondientes mediante la consulta
Set-Cookie: XSRF-TOKEN=
. Mediante un reconocimiento sistemático con
dorks de Google y GitHub, recopilaron la APP_KEY públicamente expuesta.
Utilizando su herramienta personalizada,
validaron con éxito más de 6.000 APP_KEY e identificaron que más de 400
aplicaciones de Laravel podrían verse comprometidas fácilmente mediante
ataques de ejecución remota de código.

GitGuardian señaló que la implementación actual de la función
decrypt() en Laravel presenta un problema de seguridad: deserializa
automáticamente los datos descifrados, lo que facilita la ejecución remota de
código.
«Específicamente en aplicaciones de Laravel, si los atacantes obtienen la
APP_KEY y pueden invocar la función decrypt() con una carga maliciosa,
pueden ejecutar código remoto en el servidor web de Laravel», declaró el investigador de seguridad Guillaume Valadon.
Esta vulnerabilidad se documentó inicialmente con
CVE-2018-15133, que afectaba a versiones de Laravel anteriores a la 5.6.30. Sin embargo,
este vector de ataque persiste en versiones más recientes de Laravel cuando
los desarrolladores configuran explícitamente la serialización de sesiones en
las cookies mediante la opción SESSION_DRIVER=cookie
, como se demuestra
en
CVE-2024-55556.
Cabe destacar que
CVE-2018-15133 ha sido explotada
por actores de amenazas asociados con el malware AndroxGh0st, tras escanear
internet en busca de aplicaciones de Laravel con archivos .env mal
configurados.
Análisis posteriores han revelado que el 63% de las exposiciones de APP_KEY se
originan en archivos .env (o sus variantes) que suelen contener otros
secretos valiosos, como tokens de almacenamiento en la nube,
credenciales de bases de datos y secretos asociados con plataformas de
comercio electrónico, herramientas de atención al cliente y servicios de
inteligencia artificial (IA).
Más importante aún, aproximadamente 28.000 pares APP_KEY y APP_URL se han
expuesto simultáneamente en GitHub. De estos, aproximadamente el 10% han
resultado ser válidos, lo que deja a 120 aplicaciones vulnerables a ataques
triviales de ejecución remota de código.
Dado que la configuración APP_URL especifica la URL base de la aplicación, la
exposición tanto de APP_URL como de APP_KEY crea un potente vector de ataque
que los cibercriminales pueden aprovechar para acceder directamente a la
aplicación, recuperar cookies de sesión e intentar descifrarlas con la clave
expuesta.
Borrar los secretos de los repositorios no es suficiente, especialmente
cuando ya han sido clonados o almacenados en caché por herramientas de
terceros.
Lo que los desarrolladores necesitan es una ruta de rotación clara, respaldada
por una monitorización que detecte cualquier reaparición futura de cadenas
sensibles en los registros de CI, compilaciones de imágenes y capas de
contenedores.
Este tipo de incidentes también se alinea con una clase más amplia de
vulnerabilidades de deserialización de PHP, donde herramientas como
phpggc ayudan a los atacantes a crear cadenas de gadgets que
desencadenan comportamientos no deseados durante la carga de objetos. Al
utilizarlos en entornos de Laravel con claves filtradas, estos gadgets pueden
lograr una RCE completa sin necesidad de violar la lógica ni las rutas de la
aplicación.
La revelación se produce después de que
GitGuardian revelara
el descubrimiento de la asombrosa cantidad de 100.000 secretos válidos en
imágenes de Docker accesibles públicamente en el registro de DockerHub. Esto
incluye secretos asociados con Amazon Web Services (AWS), Google Cloud y
tokens de GitHub.
Un nuevo análisis de Binarly de más de 80.000 imágenes Docker únicas que
abarcan 54 organizaciones y 3.539 repositorios también ha descubierto 644
secretos únicos que abarcan credenciales genéricas, tokens web JSON,
encabezados de autorización básica HTTP, claves de API de Google Cloud, tokens
de acceso de AWS y tokens de API de CircleCI, entre otros.
«Los secretos aparecen en una amplia variedad de tipos de archivos,
incluyendo código fuente, archivos de configuración e incluso archivos
binarios de gran tamaño, áreas donde muchos escáneres existentes fallan»,
declaró la compañía.
«Además, la presencia de repositorios Git completos dentro de imágenes de
contenedores representa un riesgo de seguridad grave y a menudo
ignorado».
Pero eso no es todo. La rápida adopción del Protocolo de Contexto de Modelo
(MCP) para habilitar flujos de trabajo con agentes en aplicaciones de IA
empresariales ha abierto
nuevos vectores de ataque, siendo uno preocupante la filtración de secretos de servidores MCP
publicados en repositorios de GitHub.
En concreto, GitGuardian descubrió que 202 de ellos filtraron al menos un
secreto, lo que representa el 5,2 % del total de repositorios. Esta cifra,
según la compañía, es
«ligeramente superior a la tasa de incidencia del 4,6 % observada en todos
los repositorios públicos, lo que convierte a los servidores MCP en una
nueva fuente de filtraciones de secretos».
Si bien esta investigación se centra en Laravel, el mismo problema de raíz
(secretos sin protección en repositorios públicos) se aplica a otras
plataformas.
Las organizaciones deberían explorar el escaneo centralizado de secretos,
las guías de refuerzo específicas de Laravel y los patrones de seguridad por
diseño para gestionar archivos .env y secretos de contenedores en
todos los frameworks.
Fuente:
THN