En resumen: Un workaround para la vulnerabilidad de PHP PHP2Shell puede reducir el riesgo, pero no sustituye a la actualización. php.net menciona para ello límites fijos de memoria y de carga, la desactivación de Session-Upload-Progress y, en PHP 8.5, fatal_error_backtraces=0. Si tampoco eso es posible a corto plazo, el BSI (Oficina Federal alemana para la Seguridad de la Información) recomienda desconectar temporalmente el servidor web de la red.
Lo que un workaround puede conseguir y lo que no
Las medidas provisionales de php.net pretenden dificultar las condiciones en las que se pueden explotar las vulnerabilidades CVE-2026-109618 y CVE-2026-109619. Expresamente no son una protección completa. Las vulnerabilidades solo están corregidas en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, o en un backport confirmado de su proveedor.
Las medidas tienen sentido cuando la actualización aún no es posible por un motivo concreto: falta una ventana de mantenimiento, hay que probar antes una aplicación, o usted opera PHP 8.1 o anterior, para el que ya no hay actualización oficial. Son entonces un puente, no una meta.
Por eso, planifique la actualización a la vez que el workaround: ¿quién la ejecuta, en qué ventana de mantenimiento y quién comprueba después que se han reiniciado todos los workers? Una transición sin fecha final corre el riesgo de convertirse en un estado permanente.
Opción 1: desconectar temporalmente el servidor de la red
El BSI ha declarado el nivel de alerta 3 (naranja) y recomienda desconectar temporalmente de la red los servidores web afectados cuando la actualización no es posible de inmediato. Algunos proveedores lo han hecho por precaución; eso no significa que esos sitios hayan sido hackeados.
Para muchas empresas, una caída de la tienda o del portal es costosa. Puede ser razonable una ponderación: acceso solo mediante VPN o direcciones IP autorizadas, una página de mantenimiento estática en lugar de la aplicación PHP, o desactivar sitios web concretos que no se necesiten en el servidor. Cuanto menos PHP sea accesible desde fuera, menor es la superficie de ataque.
Lo importante es tomar la decisión de forma consciente y dejar constancia: ¿quién decidió y cuándo mantener el servidor en línea, y con qué medidas de protección? Eso ayuda después frente a la aseguradora, la protección de datos y la dirección.
Las medidas provisionales de php.net
| Medida | Valor | Observación |
|---|---|---|
memory_limit |
-1, no sobrescribible |
fijar entonces el límite de memoria mediante contenedor o cgroup |
post_max_size |
8M sin cargas, 32M con cargas |
upload_max_filesize por debajo |
| Límite de memoria | mediante contenedor/cgroup | no mediante RLIMIT_AS ni RLIMIT_DATA |
session.upload_progress.enabled |
0 |
en php.ini, pool o configuración del servidor, no mediante ini_set() ni .user.ini |
fatal_error_backtraces |
0 |
solo PHP 8.5 |
El ajuste session.upload_progress.enabled=0 es además la solución para la vulnerabilidad comunicada el 23 de octubre, CVE-2026-115560.
Aplicar correctamente el workaround para la vulnerabilidad de PHP
Lo decisivo es el lugar. Los valores deben fijarse de modo que una aplicación no pueda sobrescribirlos. Las rutas y los nombres de servicio varían según la distribución; los ejemplos parten de PHP 8.3.
PHP-FPM, en el pool (p. ej. /etc/php/8.3/fpm/pool.d/www.conf):
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; solo PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
Apache con mod_php, en la configuración del servidor o en el VirtualHost:
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Límite de memoria mediante cgroup, aquí con systemd para el servicio FPM. Adapte el valor a su servidor:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Después, reinicie todos los workers; de lo contrario, nada de esto surte efecto: systemctl restart php8.3-fpm o, con mod_php, Apache. Cómo comprobar que ya no se ejecuta ningún proceso antiguo se explica en Reiniciar PHP-FPM y todos los workers. El refuerzo general de la configuración se describe en Configurar php.ini de forma segura.
Pruebe las cargas de archivos y los formularios grandes tras el cambio. Un post_max_size demasiado ajustado puede bloquear pedidos, formularios de candidatura o cargas de medios. Es un motivo para no retrasar mucho la actualización.
Capas de protección adicionales
Un cortafuegos de aplicaciones web o el parcheo virtual pueden ayudar como capa adicional. 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. Por eso, un WAF es un complemento, no un sustituto. Más información en WAF y parcheo virtual.
Asegure además los registros del servidor a partir del 20 de octubre. Según informes de los medios, ya se observó un primer intento de ataque el 17 de octubre; los registros son la base por si más adelante necesita aclarar si ocurrió algo antes del parche.
¿Cómo ayuda PHP SOS en concreto?
- Aclarar la situación: comprobamos si una actualización es posible a corto plazo o si hace falta una transición, y hablamos con usted de la opción de desconectar partes de la red.
- Aplicar las medidas: introducimos los valores de php.net en el lugar correcto, fijamos el límite de cgroup y reiniciamos todos los workers.
- Probar el funcionamiento: revisamos formularios, cargas de archivos y procesos de pedido tras el cambio.
- Llevar al parche: con el servicio de parcheo de PHP planificamos la actualización y después retiramos de forma controlada los valores transitorios que molesten.
Preguntas frecuentes
¿Protege el workaround por completo frente a PHP2Shell?
No. php.net califica expresamente las medidas como transitorias y no como protección completa. Reducen el riesgo hasta que se instale la actualización. El BSI recomienda desconectar temporalmente de la red los servidores sin parche.
¿Puedo fijar los ajustes mediante .htaccess o .user.ini?
Para session.upload_progress.enabled, php.net excluye expresamente ini_set() y .user.ini. También para memory_limit vale: el valor debe fijarse de modo que la aplicación no pueda sobrescribirlo. Eso se consigue en php.ini, en el pool de FPM con php_admin_value o en la configuración del servidor Apache.
¿Basta con un cortafuegos de aplicaciones web como workaround?
Como capa adicional puede ayudar. Cloudflare ha desplegado reglas de protección, pero señala por sí misma que las reglas basadas solo en los datos de la petición no bastan. Un WAF no sustituye ni la actualización ni las medidas provisionales en el servidor.
¿Qué hago si solo tengo hosting compartido?
Entonces php.ini y el reinicio dependen del proveedor de hosting. Pregunte de forma concreta si se ha instalado la actualización o se han aplicado las medidas provisionales y si se han reiniciado todos los procesos de PHP.