En resumen: Muchos consejos sobre PHP2Shell que circulan ahora en foros y redes sociales no protegen o incluso perjudican: bloquear peticiones con cookie de sesión, ocultar mensajes de error, fijar ajustes mediante .user.ini o actualizar solo el CMS. php.net es inequívoco: no existen medidas provisionales completas; la actualización de PHP con el reinicio de todos los procesos es la única vía segura.
Por qué los consejos erróneos son peligrosos en esta situación
Con una vulnerabilidad crítica que atrae mucha atención surge un mercado de soluciones rápidas. Los consejos se comparten, se resumen y se reenvían, a menudo sin las salvedades de la fuente original. En PHP2Shell se suma que, según los informes, los detalles se conocieron antes de la fecha oficial y que la situación fue confusa en los primeros días.
Un consejo erróneo perjudica doblemente. Deja la vulnerabilidad abierta y crea la sensación de haber hecho algo. Justo esa sensación hace que la verdadera actualización se quede sin hacer. Algunos consejos además paralizan el propio sitio web.
Nueve consejos sometidos a verificación
La tabla siguiente resume lo que hemos leído con frecuencia en los últimos días y lo contrasta con las afirmaciones de las fuentes primarias.
| Consejo que circula | Por qué no se sostiene | Qué vale en su lugar |
|---|---|---|
Bloquear todas las peticiones con PHPSESSID |
Rechazado expresamente por autores especializados; paraliza inicios de sesión y carritos | Actualizar PHP |
Basta session.upload_progress.enabled=0 |
Según informes especializados, no cierra ambas vulnerabilidades | Medida provisional razonable, la actualización sigue siendo obligatoria |
Fijar valores con ini_set() o .user.ini |
php.net lo desaconseja expresamente | En el servidor: php.ini, pool de FPM o configuración del servidor |
| Ocultar mensajes de error | Según php.net, no ayudan error_reporting, display_errors ni @ |
Actualizar; aun así, no mostrar públicamente la salida de errores |
Limitar la memoria mediante RLIMIT_AS o RLIMIT_DATA |
php.net advierte de que justo eso puede provocar la situación vulnerable | Límite mediante contenedor o cgroup |
| Actualizar WordPress o los plugins | La vulnerabilidad está en el intérprete de PHP, no en el CMS | Actualizar el entorno de ejecución de PHP |
| Cloudflare u otro WAF es suficiente | Protección solo para el tráfico a través del servicio; los servidores accesibles directamente siguen abiertos | WAF como capa adicional, no como sustituto |
| Recargar el servicio en lugar de reiniciarlo | Según Red Hat, una recarga no basta, los workers existentes pueden conservar el estado antiguo | Reiniciar por completo todos los workers |
| Parcheado significa limpio | Un parche no elimina el software malicioso introducido antes | Conservar los registros desde el 20 de octubre y buscar indicios |
Los tres errores más frecuentes explicados con más detalle
La prohibición de cookies
El consejo de rechazar todas las peticiones con la cookie de sesión PHPSESSID suena técnico y decidido. Los autores especializados lo rechazan expresamente. En la práctica rompe todo lo que necesita una sesión: cuentas de clientes, carritos de la compra, áreas de administración, formularios con protección contra falsificación. Una protección contra la vulnerabilidad no es.
El único ajuste que lo resuelve todo
session.upload_progress.enabled=0 figura en las recomendaciones de php.net y es la medida paliativa mencionada contra CVE-2026-115560. De ahí algunas publicaciones sacaron «PHP2Shell desactivado». Según informes especializados, este ajuste por sí solo no cierra ambas vulnerabilidades. También memory_limit=-1 elimina, según php.net, solo el desencadenante controlable; un error de memoria a un nivel más profundo puede seguir alcanzando la ruta vulnerable. En PHP 8.5, fatal_error_backtraces=0 bloquea, según php.net, solo la vía confirmada mediante backtraces.
Cómo fijar el ajuste, aun así, de forma correcta y permanente lo describe el artículo Desactivar session.upload_progress. La lista completa de medidas provisionales figura en Medidas inmediatas sin parche.
El escudo por delante
Según sus propias indicaciones, Cloudflare tiene activas desde el 21 de octubre reglas de protección, también para clientes del plan gratuito. Pero el propio Cloudflare señala límites: la protección solo actúa sobre el tráfico que pasa por Cloudflare. Si el servidor de origen es accesible directamente, se elude. Además, Cloudflare examina también la respuesta del servidor, porque la petición por sí sola no siempre basta. Por qué un WAF no sustituye la actualización lo explica el artículo ¿WAF o actualización?.
Un consejo con riesgo: filtrar peticiones de subida en el borde
No todo consejo incómodo es erróneo. Los autores especializados proponen, como medida provisional no oficial, bloquear en el proxy o en el WAF las peticiones multipart/form-data fuera de las rutas de subida reales. Eso puede reducir la superficie de ataque, pero rompe formularios y subidas si la lista de rutas permitidas está incompleta.
Quien siga este camino debería probarlo antes en un entorno de pruebas, acordarlo con los departamentos especializados y documentarlo como medida temporal. Tampoco este consejo sustituye la actualización.
Muchas soluciones WAF ofrecen para ello un modo de observación, en el que las reglas solo registran en lugar de bloquear. Deje funcionar una regla nueva así durante unos días y evalúe qué peticiones legítimas se verían afectadas. Solo después cambie a bloquear. Así evita que formularios de candidatura, portales de clientes o la subida de imágenes en la tienda dejen de funcionar sin que nadie lo note.
Cómo comprobar un consejo antes de aplicarlo
Cuatro preguntas separan los consejos útiles de los peligrosos:
- Fuente: ¿procede la recomendación de php.net, de su distribución, del BSI (Oficina Federal alemana para la Seguridad de la Información) o de un autor especializado con nombre?
- Pretensión: ¿se describe la medida como transición o como solución? En PHP2Shell, solo la actualización es una solución.
- Efecto secundario: ¿qué se rompe cuando la medida actúa? Un consejo sin indicación de efectos secundarios está incompleto.
- Lugar de aplicación: ¿se fija el ajuste en el servidor y de forma no sobrescribible, seguido de un reinicio de todos los workers?
Deje constancia de qué medidas provisionales aplicó y cuándo. Así podrá revisarlas después de forma dirigida y reconocer si una supuesta protección retrasó la verdadera actualización.
¿Cómo ayuda PHP SOS en concreto?
- Revisamos las medidas ya aplicadas en su caso y separamos las eficaces de las ineficaces.
- Aplicamos la actualización de PHP, reiniciamos todos los procesos y acreditamos el estado.
- Donde una actualización aún no es posible, aplicamos medidas provisionales según php.net en el servidor y de forma documentada.
- Con WAF y parcheo virtual complementamos la protección en el borde, sin sustituir la actualización.
Preguntas frecuentes
¿Protege bloquear las peticiones con PHPSESSID?
No. Los autores especializados rechazan expresamente este consejo que circula. Paraliza inicios de sesión, carritos de la compra y formularios sin cerrar la vulnerabilidad del intérprete.
¿Basta session.upload_progress.enabled=0 contra PHP2Shell?
No. El ajuste es una de varias medidas provisionales y, según informes especializados, no cierra ambas vulnerabilidades. Es razonable, pero no sustituye la actualización de PHP.
¿Ayuda desactivar display_errors?
Para PHP2Shell no. php.net señala que ocultar los diagnósticos mediante error_reporting, display_errors o el operador @ no ayuda. En producción, display_errors debería estar desactivado de todos modos por otras razones.
¿Cómo reconozco un consejo fiable?
Un consejo fiable cita su fuente, describe sus límites y califica las medidas provisionales como tales. Quien promete que un único ajuste hace innecesaria la actualización se equivoca con PHP2Shell.