En resumen: la vulnerabilidad de Laravel que muchos desarrolladores buscan ahora es PHP2Shell y está en el propio PHP. Una actualización de Laravel no la cierra. Importan un PHP parcheado, el reinicio de todos los procesos, incluidos los queue workers y Octane, y una revisión de .env, storage y public.
Qué significa PHP2Shell para las aplicaciones Laravel
Laravel es la base de muchos desarrollos propios: portales de clientes, herramientas internas, sistemas de reservas, API para apps. Según el equipo de PHP, las vulnerabilidades de PHP CVE-2026-109618 y CVE-2026-109619 permiten ejecutar código malicioso de forma remota y sin autenticación. Lo limpio que esté el código de Laravel no influye en ello.
Están afectados los modos de funcionamiento PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Laravel Octane puede usar FrankenPHP como servidor; entonces PHP está dentro del programa FrankenPHP o de la imagen del contenedor y se actualiza con ellos. Cómo es esto con FrankenPHP se describe en Proteger FrankenPHP.
Vulnerabilidad de Laravel: comprobar la versión de PHP y los procesos
En la línea de comandos, php artisan about muestra la versión de PHP, la versión de Laravel y ajustes importantes como el entorno y el modo de depuración. Sin embargo, esa es la versión del PHP de CLI. Las peticiones web las atiende PHP-FPM u Octane, y puede ser otra versión. En caso de duda, pida al operador que confirme qué estado de paquetes se ejecuta por todas las vías.
Las versiones corregidas de origen son 8.5.12, 8.4.27, 8.3.36 y 8.2.35; los backports pueden llevar números más antiguos. Qué versiones de PHP admite su versión de Laravel puede consultarlo, según los requisitos del sistema, en la documentación de laravel.com.
Tras la actualización viene la parte que más se olvida en Laravel: los procesos de larga duración.
# Mostrar versiones y configuración
php artisan about
# Indicar a los queue workers que terminen tras el trabajo actual
php artisan queue:restart
# Terminar Horizon para que el gestor de procesos lo reinicie
php artisan horizon:terminate
Después, los workers solo se reinician si los supervisa un gestor de procesos como Supervisor o systemd. Los servidores Octane y los contenedores deben reiniciarse por completo o desplegarse con una imagen nueva. Para configuraciones con contenedores se aplica Parchear PHP en contenedores Docker.
Dónde son vulnerables las aplicaciones Laravel
| Lugar | Contenido | Punto de control |
|---|---|---|
.env |
APP_KEY, base de datos, correo, claves de API |
Nunca debe poder consultarse desde la web |
bootstrap/cache/config.php |
Configuración en caché con secretos | Permisos, fecha de modificación |
public/ |
Raíz de documentos con index.php |
Archivos PHP adicionales |
storage/app/public |
Subidas, accesibles mediante public/storage |
Sin archivos PHP |
storage/logs/ |
laravel.log, a menudo con datos de las peticiones |
Guardar, no público |
vendor/ |
Paquetes de Composer | composer audit, comparación con composer.lock |
La carpeta storage/app/public es accesible mediante un enlace simbólico en public/storage. Según la configuración del servidor, un archivo PHP depositado allí puede ejecutarse directamente. Bloquéelo a nivel del servidor web.
APP_DEBUG debe estar en false en producción. Una página de error con salida de depuración puede mostrar variables de entorno, rutas y partes del código, y facilita el trabajo a cualquier atacante.
Interfaces de administración y paquetes como riesgo
Las aplicaciones Laravel no tienen una interfaz de administración uniforme. Con frecuencia son áreas propias o paquetes como Filament o Nova. Compruebe quién tiene derechos de administrador, si el inicio de sesión cuenta con un segundo factor y si las rutas de administración tienen que ser accesibles desde fuera. También los tokens de API, por ejemplo de Sanctum o Passport, deberían revocarse y emitirse de nuevo ante una sospecha.
Compruebe además si herramientas del desarrollo son accesibles en producción, como barras de depuración, Telescope o rutas de prueba. Suelen mostrar peticiones, consultas y configuración, y deben ponerse tras un inicio de sesión o eliminarse por completo del entorno de producción.
Los paquetes de Composer son el segundo gran bloque. Cada dependencia aporta código propio, y los paquetes sin mantenimiento bloquean más adelante las actualizaciones de PHP. composer audit muestra vulnerabilidades conocidas, pero no sustituye a una revisión del código propio.
Lo que puede y no puede hacer una actualización de Laravel
Una actualización de Laravel o de paquetes concretos cierra errores conocidos en ese código. No parchea PHP, no reinicia los workers, no renueva un APP_KEY filtrado y no elimina archivos de storage o public. Si antes del parche ha ocurrido algo solo se puede aclarar revisando registros, archivos y base de datos.
Para los equipos con pipeline de despliegue: la actualización de PHP también debe llegar al entorno de build y a las imágenes base; de lo contrario, el siguiente despliegue vuelve a traer una versión antigua. Compruebe además si los entornos de staging o de revisión son accesibles públicamente. A menudo funcionan con APP_DEBUG=true y datos reales y se pasan por alto fácilmente en las actualizaciones de seguridad.
¿Cómo ayuda PHP SOS en concreto?
- Revisamos el PHP web, el PHP de CLI y el PHP de los workers de su aplicación Laravel y acompañamos el reinicio ordenado de todos los procesos.
- Guardamos los registros a partir del 20/10/2026, la base de datos y el estado del código, y lo contrastamos con su repositorio.
- Revisamos
.env, la caché de configuración,storage,public, las cuentas de administrador y los tokens de API. - Para una revisión más profunda del código propio, intermediamos una auditoría de seguridad o un test de penetración a través de socios especializados.
Preguntas frecuentes
¿Debo actualizar Laravel por PHP2Shell?
Una actualización de Laravel no cierra PHP2Shell, porque la vulnerabilidad está en el intérprete de PHP. Aun así, mantenga Laravel actualizado. Para PHP2Shell necesita un PHP parcheado y el reinicio de todos los procesos de PHP, también de los workers.
¿Por qué en Laravel suele no bastar con reiniciar PHP-FPM?
Los queue workers, Horizon, Octane y el scheduler se ejecutan como procesos PHP propios desde la línea de comandos. Cargan PHP una sola vez al arrancar y después siguen trabajando con la versión antigua en memoria hasta que se reinician.
¿Qué hacer si el archivo .env pudo haberse filtrado?
Entonces debería renovar APP_KEY, la contraseña de la base de datos y todas las claves de servicios externos. Tenga en cuenta que un nuevo APP_KEY cierra las sesiones existentes y hace ilegibles los datos cifrados con la clave antigua; planifíquelo con sus desarrolladores.