CVE-2025-54068: RCE crítico en Livewire v3, ¿está tu Laravel afectado?

El 20 de marzo de 2026, CISA añadió CVE-2025-54068 a su catálogo Known Exploited Vulnerabilities (KEV). Es una vulnerabilidad crítica de ejecución remota de código (RCE) en Livewire v3 que afecta potencialmente a millones de aplicaciones Laravel, incluidas todas las que usan Filament v3 o superior. El parche existe desde julio de 2025, pero la inclusión en KEV confirma que se está explotando activamente en ataques reales, vinculados al APT iraní MuddyWater.

Si tienes un proyecto Laravel con Livewire o Filament en producción, deja de leer y comprueba tu versión ahora.

Compatibilidad / requisitos

• Versiones afectadas: Livewire desde 3.0.0-beta.1 hasta 3.6.3 inclusive

• Versiones seguras: Livewire 3.6.4 o superior

• No afectados: Livewire v1 y v2

• Afectación indirecta: Filament v3, v4 y v5 dependen de Livewire v3+, así que también están expuestos si no se ha actualizado la dependencia transitiva

Cómo comprobar tu versión por SSH

Conéctate al servidor y, desde la raíz del proyecto Laravel, ejecuta:

composer show livewire/livewire | grep versions

Si Composer no está disponible globalmente, lee directamente el composer.lock (refleja lo que realmente está instalado):

grep -A 1 '"name": "livewire/livewire"' composer.lock | grep version

Resultados posibles:

• "version": "v3.6.4" o superior → estás a salvo

• Cualquier versión 3.0.x a 3.6.3 → vulnerable, parchea ya

• v2.x o v1.x → no afectado por este CVE (pero estás en versiones sin soporte, eso es otro problema)

Cómo parchear

composer update livewire/livewire

Y para fijar un mínimo seguro en composer.json y evitar regresiones futuras al reinstalar:

{
    "require": {
        "livewire/livewire": "^3.6.4"
    }
}

Tras actualizar, verifica con composer show livewire/livewire y haz deploy. No hay workaround intermedio: el equipo de Livewire ha confirmado que la única mitigación es actualizar.

Si gestionas múltiples proyectos, automatiza la auditoría:

composer audit

Este comando consulta el Packagist Security Advisories Database y te lista todas las dependencias con CVE conocidos.

Qué es y por qué es grave

Livewire v3 mantiene el estado de los componentes en el cliente entre requests. Cada vez que el usuario interactúa con un componente, el frontend envía un "snapshot" con las propiedades actualizadas, y el servidor las rehidrata (es decir, reconstruye los objetos PHP a partir de los datos serializados del cliente).

El bug está en el método hydrateForUpdate() de la clase Livewire\Mechanisms\HandleComponents\HandleComponents. La implementación original llamaba directamente a hydrate() sobre datos del cliente sin validación adicional. Un atacante puede construir un payload con tuplas sintéticas o propiedades anidadas removidas que evade incluso el checksum del APP_KEY, y termina interpretándose como código PHP ejecutable.

Esto se clasifica como CWE-94 (Improper Control of Generation of Code) y cumple las tres condiciones que hacen una RCE realmente peligrosa:

• Sin autenticación: no hace falta estar logueado

• Sin interacción de usuario: no requiere clicks ni ingeniería social

• Accesible por red: basta con poder hacer POST a cualquier endpoint Livewire

El CVSS 4.0 es 9.2 crítico. El EPSS (probabilidad de explotación en los próximos 30 días) es del 94.68%. Existe un exploit público funcional que detecta automáticamente la versión de Livewire, localiza snapshots vulnerables y dispara el RCE sin necesidad de conocer el APP_KEY.

Cómo es el parche

El parche oficial introduce un nuevo método hydratePropertyUpdate() que añade validación específica antes de hidratar. La idea: nunca tratar la entrada del cliente como confiable, ni siquiera en mecanismos internos del framework que asumían integridad por checksum. El checksum verifica que el cliente no manipuló el snapshot original, pero no impide que un atacante construya uno desde cero con estructura maliciosa.

Lecciones para tu propio código

Más allá de actualizar, este CVE deja un par de principios útiles:

1. El checksum no es validación de contenido. Verificar integridad de un payload (que no fue alterado en tránsito) es distinto de validar que su estructura es segura. Si tu código deserializa datos del cliente, valida la forma incluso si confías en el origen.

2. composer audit debería estar en tu pipeline de CI. Es una línea más en tu workflow de GitHub Actions y te avisa de CVEs en dependencias antes del deploy.

3. Fija mínimos de seguridad explícitos en composer.json para librerías críticas. ^3.6.4 es mejor que ^3.0 cuando hay un CVE conocido por debajo de esa versión.

4. El estado del cliente nunca es confiable. Frameworks como Livewire o Hotwire (Rails) facilitan mucho el desarrollo precisamente porque ocultan el round-trip cliente-servidor, pero esa abstracción no elimina la superficie de ataque, solo la mueve.

Si sospechas que ya te explotaron

Revisa logs en busca de:

• Requests POST a /livewire/update con payloads anómalos o codificados

• Procesos hijos inesperados spawned desde PHP-FPM o el web server

• Ficheros .php nuevos en directorios de uploads o public

• Conexiones salientes anómalas desde el servidor

Y, en cualquier caso, rota credenciales (APP_KEY, tokens de API, claves de servicios externos) y revisa los últimos commits en el repositorio del proyecto por si hay deploy via Git en el server.

Referencias

• GitHub Advisory: GHSA-29cq-5w36-x7w3

• NVD: CVE-2025-54068

• CISA KEV catalog (entrada del 20 de marzo de 2026)