PHP2Shell: qué debe hacer ahora si su web usa WordPress

PHP2Shell es un par de vulnerabilidades críticas en el propio PHP, publicadas el 21 de octubre de 2026 y con una puntuación CVSS de 9,2. En un entorno PHP sin parchear, un atacante sin cuenta puede ejecutar código en el servidor o leer memoria que contiene contraseñas, tokens de sesión y claves de API. Los investigadores lo demostraron contra instalaciones actuales de WordPress. Actualizar WordPress, su tema o sus plugins no lo soluciona: hay que actualizar la versión de PHP sobre la que funciona su web.

Esta guía explica qué es PHP2Shell, cómo comprobar si su web está afectada, qué preguntar a su proveedor de hosting y qué hacer si la actualización no puede hacerse hoy.

Qué es PHP2Shell

La investigación de Wiz Research, OpenAI Codex Security y Calif encontró dos clases relacionadas de fallos de seguridad de memoria en el motor de PHP:

• CVE-2026-109618, corrupción por falta de memoria. La forma en que PHP gestiona el agotamiento de la memoria puede corromper su estado. Un atacante puede aprovecharlo para ejecutar código como el proceso web de PHP (worker), sin iniciar sesión.
• CVE-2026-109619, estado global obsoleto entre peticiones. Los datos de una petición pueden sobrevivir hasta la siguiente. Esto provoca un use-after-free que puede filtrar memoria del worker o ejecutar código.

Como el fallo está en PHP, su propio código no tiene por qué contener ningún error. Según los investigadores, incluso una página «Hello World» en una versión de PHP afectada puede quedar expuesta. WordPress, Drupal y Joomla fueron simplemente las aplicaciones que usaron para demostrar la ejecución remota de código sin autenticación. El equipo de PHP publicó versiones corregidas ese mismo día.

Para un sitio WordPress, hay dos consecuencias que importan más:

1. Toma del servidor. Ejecutar código como el worker de PHP suele significar que el atacante puede modificar archivos, añadir un administrador, instalar una puerta trasera o llegar a la base de datos.
2. Robo silencioso de datos. La filtración de memoria funciona sin ejecutar código malicioso, así que puede dejar pocas huellas. La memoria de un worker de PHP con mucho tráfico puede contener contraseñas y cookies de otros visitantes, la contraseña de su base de datos y claves de API.

¿Está afectada mi web?

Casi con toda seguridad, salvo que su PHP se actualizara el 21 de octubre de 2026 o después. Los investigadores encontraron versiones afectadas desde PHP 5.4. Estas son las primeras versiones corregidas de cada rama con soporte:

PHP 8.1, 8.0 y todas las versiones 7.x ya no reciben soporte del proyecto PHP y no aparecen en esta tabla. Si su web funciona con una de ellas, no hay ninguna versión corregida que instalar: debe pasar a una rama con soporte.

Para ver su versión exacta en WordPress, abra Herramientas → Salud del sitio → Información y despliegue Servidor. La línea «Versión de PHP» muestra el número completo, por ejemplo 8.3.36. Las dos primeras partes (8.3) no bastan: lo que importa es el último número.

Cómo solucionarlo

La única solución completa es un entorno PHP parcheado, seguido de un reinicio.

1. Actualice PHP en todos los entornos. En su propio servidor, instale los paquetes actualizados de su distribución en cuanto se publiquen, o la versión oficial de php.net. En un hosting gestionado o compartido, es el proveedor quien actualiza PHP; pregúntele directamente si su plan ya usa la versión corregida.
2. Reinicie PHP. Un paquete PHP nuevo no sirve de nada hasta que se sustituyen los procesos en ejecución. Reinicie PHP-FPM, Apache con mod_php y cualquier worker de PHP de larga duración.
3. Compruebe el resultado. Vuelva a mirar Salud del sitio. La versión de PHP debe ser ahora igual o superior a la versión corregida de su rama.
4. No olvide los demás entornos. Los sitios de pruebas (staging), una segunda versión de PHP seleccionada en su panel de hosting, el PHP que usan las tareas cron y WP-CLI, y las imágenes de contenedores también cuentan.

Si su panel de hosting tiene un selector de versión de PHP, elegir «8.3» u «8.4» solo es seguro si el proveedor ya ha instalado la compilación parcheada detrás de esa etiqueta. Salud del sitio le dice la verdad.

Si no puede actualizar hoy

Los investigadores enumeran medidas temporales. Cada una bloquea algunas vías de ataque, ninguna las bloquea todas y algunas pueden afectar a su web, así que pruébelas primero:

• fatal_error_backtraces = 0 si su versión de PHP lo admite.
• Reduzca post_max_size y max_input_nesting_level tanto como lo permitan sus formularios y subidas de archivos, y establezca session.upload_progress.enabled = 0 si nada utiliza el progreso de subida.
• Recicle los workers de PHP-FPM con más frecuencia mediante un pm.max_requests más bajo (esto cuesta rendimiento).
• memory_limit = -1 elimina la vía del límite de memoria en la que se apoyan algunos ataques, pero deja el agotamiento de memoria en manos del sistema operativo. Úselo solo junto con un límite del sistema operativo como memory.max de cgroup v2, y no lo sustituya nunca por RLIMIT_AS o RLIMIT_DATA, que según el aviso de seguridad de PHP pueden desencadenar el mismo fallo.

Ocultar los errores de PHP (display_errors, error_reporting o @) no es una de estas medidas: el proyecto PHP afirma que no ayuda.

Los proveedores de cortafuegos y CDN han publicado reglas para PHP2Shell. Pueden reducir la exposición, pero los investigadores dejan claro que una regla de protección no sustituye a la actualización de PHP.

Señales a vigilar

Ninguna línea de registro demuestra por sí sola un ataque. Los investigadores citan señales que merece la pena investigar: cookies PHPSESSID inusualmente grandes o mal formadas en las respuestas, peticiones multipart extrañas seguidas de errores de límite de memoria o de ráfagas de respuestas HTTP 500, y workers de PHP que se bloquean o se reinician sin motivo. Que no aparezcan no demuestra que su web esté limpia, porque la filtración de memoria puede no dejar nada en los registros de WordPress.

Si detecta estas señales, trátelo como un posible incidente. Nuestra guía sobre las señales de un WordPress hackeado le ayudará con las primeras comprobaciones. Como la memoria filtrada puede contener secretos, después de parchear cambie la contraseña de la base de datos, las claves y sales de wp-config.php y cualquier clave de API. Si pueden haberse expuesto datos personales, empieza a correr el plazo del RGPD: consulte nuestra guía de notificación de brechas en 72 horas.

Por dónde empezar

1. Abra Herramientas → Salud del sitio → Información → Servidor y anote la versión exacta de PHP de cada sitio que gestione.
2. Compárela con la tabla anterior. Todo lo que esté por debajo de la versión corregida, o en PHP 8.1 o anterior, requiere actuar hoy.
3. Actualice PHP o pida a su proveedor de hosting la versión parcheada, y asegúrese después de que PHP-FPM o Apache se reinicia.
4. Vuelva a revisar Salud del sitio y guarde la captura de pantalla como prueba de la corrección.
5. Revise sus registros en busca de las señales anteriores y renueve los secretos si algo parece extraño.

Fuentes: php2shell.com, anuncio de la PHP Foundation, Wiz Research.