En resumen: la seguridad en Symfony tras PHP2Shell significa: parchear PHP, reiniciar todos los procesos, incluidos los workers de Messenger, y revisar después secrets, caché y profiler. La vulnerabilidad está en PHP, no en Symfony; una actualización de Symfony por sí sola no la cierra.
Por qué PHP2Shell afecta a todo proyecto Symfony
Symfony es la base de muchas aplicaciones empresariales, API y portales, y además forma parte de sistemas como Shopware 6 y Contao. Según el equipo de PHP, las vulnerabilidades de PHP CVE-2026-109618 y CVE-2026-109619 permiten ejecutar código malicioso sin autenticación. Que la aplicación esté bien programada no influye en ello.
El equipo de PHP clasifica el riesgo como el más alto en mod_php, pero también están afectados PHP-FPM, php-cgi, FrankenPHP y LiteSpeed. Los proyectos Symfony que se ejecutan mediante Symfony Runtime con FrankenPHP u otros servidores de ejecución permanente necesitan, tras la actualización, un reinicio completo o una imagen nueva.
Seguridad en Symfony: comprobar la versión de PHP y los procesos
php bin/console about muestra la versión de Symfony, el entorno, el modo de depuración y la versión de PHP de la línea de comandos. Pero las peticiones web se ejecutan mediante PHP-FPM o un servidor de aplicaciones, y puede ser otra versión. Compruebe ambas vías o pida al operador que las confirme.
Las versiones corregidas de origen son 8.5.12, 8.4.27, 8.3.36 y 8.2.35; los backports de las distribuciones suelen llevar números más antiguos. Qué versiones de PHP admite su versión de Symfony puede consultarlo, según los requisitos del sistema, en la documentación de symfony.com.
# Mostrar entorno, modo de depuración y versión de PHP
php bin/console about
# Hacer que los workers de Messenger terminen tras el mensaje actual
php bin/console messenger:stop-workers
# Vulnerabilidades conocidas en las dependencias
composer audit
Si hay varias instancias detrás de un balanceador de carga o en contenedores, cada una debe estar parcheada y reiniciada. Una instancia olvidada sigue atendiendo parte de las peticiones con el PHP antiguo.
Los workers de Messenger, los comandos cron y otros procesos en segundo plano cargan PHP una sola vez al arrancar. Hasta que se reinician, se ejecutan con el PHP antiguo en memoria. Un gestor de procesos debe volver a ponerlos en marcha tras la parada.
Dónde son vulnerables las aplicaciones Symfony
| Lugar | Contenido | Punto de control |
|---|---|---|
.env, .env.local, .env.local.php |
Variables de entorno, a menudo base de datos y claves de API | No accesibles desde el webroot; renovar los valores ante una sospecha |
config/secrets/prod/ |
Secrets cifrados | La clave privada de descifrado no pertenece al repositorio |
public/ |
Raíz de documentos con index.php |
Archivos PHP adicionales |
var/cache/prod/ |
Contenedor generado y plantillas como PHP | Borrar y regenerar ante una sospecha |
var/log/ |
Registros | Guardar |
config/packages/security.yaml |
Firewalls, roles, reglas de acceso | Cambios inesperados |
La caché es un escondite subestimado. Symfony genera allí archivos PHP que se cargan en cada petición. Una modificación de estos archivos no se nota en el repositorio, porque la caché no está versionada.
En producción deben estar APP_ENV=prod y APP_DEBUG=0, y el WebProfilerBundle no debe estar activo allí. Un profiler accesible públicamente en /_profiler revela la configuración y los datos de las peticiones.
Áreas de administración, bundles y dependencias
Según su estructura, los proyectos Symfony tienen áreas de administración propias, a menudo con bundles como EasyAdmin o Sonata. Compruebe en security.yaml qué rutas exigen qué roles, y en la base de datos quién tiene esos roles. Las rutas de administración que solo se necesitan internamente deberían limitarse a redes conocidas a nivel del servidor web.
Los bundles y los paquetes de Composer son código ajeno con sus propias vulnerabilidades. composer audit muestra problemas conocidos; encontrará más detalles en Comprobar vulnerabilidades en las dependencias de Composer. Los paquetes obsoletos son además la razón más frecuente de que una actualización de PHP en proyectos Symfony tarde más de lo previsto.
Lo que logra una actualización de Symfony y lo que no
Una actualización de componentes de Symfony cierra errores del framework. No parchea PHP, no reinicia los workers, no renueva secrets filtrados y no elimina una caché manipulada. Si hay indicios de un ataque se describe en ¿Estoy ya comprometido?. Como no hay indicadores de compromiso confirmados, ayuda sobre todo observar comportamientos inusuales, como procesos inesperados o conexiones salientes.
Si el proyecto se entrega como contenedor, el nuevo PHP debe ir en la imagen base. Reconstruya la imagen aunque el código no haya cambiado y despliéguela en todos los entornos. Una mirada al Dockerfile muestra qué imagen base se usa; una etiqueta antigua fijada impediría de lo contrario que la reconstrucción reciba siquiera el PHP parcheado. Encontrará los detalles en Parchear PHP en contenedores Docker.
¿Cómo ayuda PHP SOS en concreto?
- Determinamos qué PHP utilizan la web, la CLI y los workers de su proyecto Symfony y acompañamos el reinicio ordenado.
- Guardamos los registros a partir del 20/10/2026 y contrastamos el código del servidor con su repositorio.
- Revisamos los archivos de entorno, los secrets, la caché, los ajustes del profiler y los roles de administración.
- Para la observación continua de procesos y conexiones ofrecemos monitorización de seguridad.
Preguntas frecuentes
¿Está Symfony afectado por PHP2Shell?
Symfony en sí no tiene ninguna vulnerabilidad nueva. PHP2Shell está en PHP, es decir, en el entorno de ejecución de toda aplicación Symfony. La vulnerabilidad se cierra con una actualización de PHP o un backport confirmado y el reinicio de todos los procesos de PHP.
¿Cómo detengo los workers de Messenger tras una actualización de PHP?
Con php bin/console messenger:stop-workers se indica a los workers en ejecución que terminen tras el mensaje actual. Un gestor de procesos como Supervisor o systemd los reinicia entonces con el PHP nuevo.
¿Por qué es peligroso el profiler de Symfony en producción?
El profiler muestra peticiones, configuración y a menudo variables de entorno. Si está activo en un servidor público, cualquiera puede consultar esa información. Solo debe estar en el entorno de desarrollo.
¿Qué ocurre con la caché tras un ataque?
La caché de var/cache contiene código PHP generado. Un atacante puede depositar allí código que se ejecute en cada petición. Ante una sospecha, la caché debería borrarse y regenerarse a partir del código fuente revisado.