En resumen: El parcheo virtual para PHP cubre el tiempo hasta que se instala la actualización real. Para ello combinamos reglas de un cortafuegos de aplicaciones web (WAF) con las medidas provisionales que php.net ha publicado sobre PHP2Shell, y fijamos desde el principio el camino hacia el parche ordinario. No ofrece una protección completa, pero reduce el riesgo durante el periodo transitorio.
Cuándo tiene sentido el parcheo virtual para PHP
Ante PHP2Shell, el BSI (Oficina Federal alemana para la Seguridad de la Información) recomienda actualizar de inmediato y, si no es posible, desconectar temporalmente de la red los servidores web. Para muchas empresas, ninguna de las dos cosas es factible de inmediato: una tienda debe seguir accesible, un desarrollo propio necesita una prueba antes de la actualización, o el servidor funciona con PHP 8.1 o anterior, para el que ya no hay actualizaciones oficiales.
En estos casos el parcheo virtual es un puente. No sustituye la decisión de si sería más adecuado el funcionamiento fuera de línea. Esa valoración la hace usted; nosotros aportamos la valoración técnica.
Por qué un WAF por sí solo no basta
Cloudflare informó de intentos de ataque observados y desplegó reglas de protección, pero advierte de que las reglas basadas solo en los datos de la petición no bastan. El motivo está en el tipo de vulnerabilidades. En CVE-2026-109618, un estado de falta de memoria (Out of Memory) puede interrumpir PHP mientras los datos de la petición están inicializados solo en parte. En CVE-2026-109619, un estado interno puede persistir tras liberar la memoria y ser aprovechado por una petición posterior en el mismo worker. Fallos así dependen del estado del servidor, no solo del contenido de una petición individual.
Por eso apostamos por varias capas: reglas WAF por delante del servidor, medidas provisionales en el propio PHP y una vigilancia reforzada del servidor. Cada capa detiene una parte, ninguna basta por sí sola. Juntas le dan el tiempo para instalar la actualización de forma ordenada.
Las medidas provisionales según php.net
php.net menciona varios ajustes que reducen el riesgo, expresamente sin protección completa. Es importante que las aplicaciones no puedan sobrescribir estos valores. Un ejemplo de un pool de PHP-FPM con cargas de archivos:
; Medidas provisionales PHP2Shell (sin protección completa), después reiniciar todos los workers
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; solo PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
Sin cargas de archivos, php.net recomienda post_max_size = 8M. Como se elimina memory_limit, debe añadirse un límite de memoria a nivel de contenedor o cgroup, no mediante RLIMIT_AS ni RLIMIT_DATA. El ajuste session.upload_progress.enabled=0 pertenece a php.ini, al pool de FPM o a la configuración del servidor, no a ini_set() ni a .user.ini. Es además la solución para la indicación sobre CVE-2026-115560. Todas las medidas, resumidas, figuran en Medidas inmediatas si todavía no puede parchear.
Las medidas provisionales solo surten efecto tras reiniciar todos los workers de PHP. Y solo protegen frente a ataques futuros: no responden a la pregunta de si alguien había entrado antes.
Cuándo es mejor el funcionamiento fuera de línea
El parcheo virtual no es la respuesta adecuada en todas las situaciones. En algunas constelaciones aconsejamos seguir al BSI y desconectar temporalmente el servidor web de la red hasta que se haya parcheado:
- el servidor funciona con Apache y mod_php, donde el equipo de PHP considera el riesgo más alto y se demostró un exploit antes de que se ejecute siquiera el código de la aplicación
- en el servidor hay datos especialmente sensibles, por ejemplo datos de salud, de clientes de despachos o de pago
- no hay forma de fijar las medidas provisionales de manera definitiva en la configuración del servidor, por ejemplo en determinados paquetes de hosting compartido
- ya existen indicios de que el servidor ha sido atacado
Un funcionamiento temporal fuera de línea no significa que su sitio web haya sido hackeado. Algunos proveedores han desconectado sitios web por precaución. Una página de aviso breve y objetiva para los visitantes suele ser entonces mejor solución que una caída sin explicación.
¿Cómo ayuda PHP SOS en concreto?
- Revisar la situación: registramos las versiones de PHP, los modos de ejecución y las capas de protección existentes, como CDN, WAF o proxy inverso. En mod_php señalamos el mayor riesgo que el equipo de PHP ve allí.
- Construir las capas: activamos o completamos reglas WAF, fijamos las medidas provisionales de forma definitiva en la configuración del servidor y limitamos la memoria mediante contenedor o cgroup. Para las configuraciones con Nginx nos guiamos por Proteger Nginx con PHP-FPM.
- Reinicio y prueba: se reinician todos los procesos de PHP y después comprobamos las cargas de archivos, los formularios, el inicio de sesión y la caja.
- Vigilar: durante el periodo transitorio prestamos más atención a los bloqueos de workers, los picos de memoria y los procesos inusuales.
- Planificar el parche: fijamos cuándo y cómo llegará la actualización ordinaria y la aplicamos con el servicio de parcheo de PHP.
Lo que recibe, lo que necesitamos y lo que no prometemos
Recibirá una documentación de todas las reglas y ajustes aplicados con su justificación, los resultados de las pruebas y un plan de plazos y medidas para el parche real. De usted necesitamos el acceso al servidor o al panel, el acceso al CDN o al WAF si existe, una persona de contacto técnica e información sobre las funciones de carga de archivos de sus aplicaciones.
No prometemos que el parcheo virtual impida un ataque. Reduce el riesgo durante un tiempo limitado. Con PHP 8.1 y anteriores no es un estado permanente; aquí la migración a una versión con soporte debe formar parte del plan.
Preguntas frecuentes
¿Qué es el parcheo virtual?
El parcheo virtual consiste en proteger una vulnerabilidad conocida por delante de la aplicación, en lugar de modificar el propio código. Suele hacerse con un cortafuegos de aplicaciones web (WAF) o con cambios de configuración. Es una solución puente, no un sustituto de la actualización.
¿Basta con el WAF de mi proveedor de CDN frente a PHP2Shell?
Por sí solo, por lo general no. Cloudflare ha desplegado reglas de protección, pero advierte por sí misma de que las reglas basadas solo en los datos de la petición no bastan. El WAF es una capa adicional junto a las medidas provisionales y el parche.
¿Durante cuánto tiempo puedo confiar en el parcheo virtual?
Lo menos posible. Debe cubrir el tiempo hasta la actualización ordinaria, por ejemplo hasta que haya una ventana de mantenimiento libre o se haya probado una aplicación. Con PHP 8.1 y anteriores debe ir acompañado de un plan de migración.
¿Pueden las medidas provisionales afectar a mi sitio web?
Sí, es posible. Unos límites de carga más pequeños pueden impedir cargas de archivos grandes, y desactivar Session-Upload-Progress afecta a los indicadores de progreso al subir archivos. Probamos las funciones más importantes después de cada cambio.