PHP2Shell: ¿está en riesgo mi sitio WordPress y qué hacer?

Cualquier sitio WordPress que funcione con una versión de PHP de php.net anterior a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 es vulnerable a PHP2Shell (los paquetes de las distribuciones Linux tienen sus propios números de versión, más abajo lo explicamos). Estas cuatro versiones de PHP salieron el 21 de octubre de 2026 y corrigen dos vulnerabilidades críticas que permiten ejecutar código de forma remota sin iniciar sesión. El fallo está en PHP, así que actualizar WordPress, el tema o los plugins no lo elimina. Hay que actualizar PHP en el servidor o asegurarse de que el hosting ya lo ha hecho.

El aviso de cada una de las cuatro versiones en php.net incluye la misma frase:

No hay mitigaciones completas, actualizar es la única opción segura.

(traducción propia, php.net, anuncios de las versiones del 21 de octubre de 2026)

#Qué es PHP2Shell

PHP2Shell son dos errores del motor de PHP que, según la página de los propios investigadores, descubrieron Calif, OpenAI y Wiz. La investigación y la descripción son obra de Ryan Austin, de Calif, y los errores se encontraron dentro de la iniciativa Patch the Planet de OpenAI (Calif). Wiz Research publicó su propio análisis (Wiz). El proyecto PHP los registra como dos vulnerabilidades:

Ambas son errores de seguridad de memoria del tipo use-after-free en la forma en que PHP gestiona los errores fatales, incluidos los de falta de memoria, y una petición HTTP manipulada puede provocarlos antes de que se ejecute cualquier código de WordPress. Las entradas de la base de datos GitHub Security Advisories del repositorio php-src se publicaron el 21 de octubre de 2026 a las 13:34 UTC. Señalan como vulnerables todas las versiones inferiores a 8.2.35, 8.3.36, 8.4.27 y 8.5.12 (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp).

Según la cronología que publicó Calif, los investigadores comunicaron el primer error al proyecto PHP el 11 de agosto de 2026, PHP confirmó el 15 de agosto que su prueba de concepto de ejecución remota de código funcionaba, y las versiones corregidas salieron el 21 de octubre de 2026 (Calif).

Un día antes, el 20 de octubre, el equipo de seguridad de PHP anunció la publicación para el 21 de octubre a las 14:00 UTC e indicó que ambas vulnerabilidades tienen una puntuación de 9.2 en la escala CVSS v4.0 (php.net, anuncio del 20 de octubre).

Hacia las 16:05, hora peninsular española (14:05 UTC), la web de Wordfence solo mostraba este mensaje: “Los servicios de Wordfence no están disponibles temporalmente mientras implementamos medidas de mitigación para la vulnerabilidad PHP2Shell, que aún no tiene parche. Gracias por tu paciencia.” (traducción propia, web wordfence.com, estado del 21 de octubre de 2026 hacia las 16:05). Al volver a comprobarlo a las 17:16, hora peninsular (15:16 UTC), la web seguía mostrando solo ese mensaje. Incluso un proveedor de seguridad para WordPress desactivó sus propios servicios durante ese tiempo para aplicar protecciones.

De la publicación de Wiz Research, al propietario de un sitio le afectan tres conclusiones:

• son vulnerables las versiones de PHP desde la 5.4,
• en las pruebas de Wiz, la ejecución remota de código sin autenticación funcionó en la imagen de contenedor wordpress:latest, y también en Drupal y Joomla,
• un error independiente permite leer un fragmento de la memoria del proceso PHP, donde puede haber contraseñas, tokens de autenticación, claves de API y certificados, incluso cuando la aplicación no inicia ninguna sesión (session_start()).

Wiz señala además que, aparte de los cuatro errores descritos, existen otras variantes del mismo problema, y que la corrección del proyecto PHP las elimina todas (Wiz).

#¿Es vulnerable mi sitio WordPress?

Sí, si funciona con una versión de PHP inferior a la versión corregida de su rama. Según php.net, está en riesgo cualquier instalación de PHP que atienda peticiones web: PHP-FPM, Apache con el módulo mod_php, php-cgi, FrankenPHP y LiteSpeed. php.net atribuye el mayor riesgo a las configuraciones con mod_php, para las que existe un exploit demostrado que se lanza con una petición sin autenticar, antes de que arranque el código de la aplicación (php.net).

La versión de WordPress, del tema y de los plugins no importa aquí, porque el error está en el intérprete de PHP y las actualizaciones automáticas de WordPress no tocan el PHP del servidor. Tampoco protege la calidad del código del sitio: según Wiz, hasta una aplicación sencilla tipo “Hello World” en una versión vulnerable de PHP puede ser objetivo de un ataque. Un plugin de seguridad funciona dentro de WordPress, y la petición puede provocar el error antes de que WordPress se cargue.

Una tienda WooCommerce tiene más que perder en esta situación que una web corporativa. En la base de datos y en la configuración están los datos de los clientes, los pedidos y las claves de las pasarelas de pago, y la exposición de la memoria del proceso afecta justo a ese tipo de secretos.

Calif confirmó la ejecución remota de código sin autenticación en WordPress 7.1.2 y, entre otras aplicaciones, también en Magento 2.4.9, phpMyAdmin 5.2.3 y WHMCS (Calif). En nuestra opinión, un phpMyAdmin o un panel de cliente que funcione con el PHP del mismo servidor queda expuesto de la misma forma, así que el servidor necesita la actualización de PHP aunque el propio WordPress no sea accesible.

Los sitios estáticos quedan fuera del alcance de este fallo. Si el sitio se genera en archivos HTML y el servidor no ejecuta PHP al atender peticiones, el aviso de php.net no le afecta, porque describe instalaciones de PHP que atienden peticiones web.

#Cómo comprobar la versión de PHP en un sitio WordPress

El camino más sencillo pasa por el escritorio de WordPress:

1. Inicia sesión como administrador.
2. Abre Herramientas, Salud del sitio.
3. Ve a la pestaña Información y despliega la sección Servidor.
4. Lee la fila de la versión de PHP.

Compara el número con la tabla:

Las fechas de soporte proceden de la tabla de versiones con soporte de php.net.

La versión de PHP que aparece en Salud del sitio es la que sirve la web. El panel del hosting puede mostrar otra versión para la línea de comandos o para otro dominio de la misma cuenta, así que lo que cuenta es la lectura de WordPress.

La excepción son los paquetes de las distribuciones Linux. Según php.net, las distribuciones y los proveedores de soporte LTS recibieron las correcciones antes y publican sus propios paquetes (php.net). Una distribución aplica la corrección en su propia versión de PHP y mantiene su número. Ubuntu 24.04 LTS corrigió PHP con el paquete 8.3.6-0ubuntu0.24.04.13 (USN-8948-1), así que un sitio ya corregido en un servidor así sigue mostrando 8.3.6 en Salud del sitio. Debian 13 (trixie) recibió php8.4 en la versión 8.4.27-1~deb13u1 (DSA-6574-1), mientras que el rastreador de seguridad de Debian seguía marcando php8.2 de Debian 12 (bookworm) como vulnerable cuando lo comprobamos, el 21 de octubre de 2026 a las 15:14 UTC (Debian security tracker). En un VPS con PHP del repositorio de la distribución, el número de versión por sí solo no zanja la cuestión. Comprueba en el aviso de seguridad de la distribución o en el registro de cambios del paquete si la actualización incluye las correcciones de CVE-2026-109618 y CVE-2026-109619 y, en un hosting, pregunta a la empresa de hosting.

#Qué hacer si el hosting aún no ha actualizado PHP

En un hosting compartido, la actualización de PHP la hace la empresa de hosting. Como propietario del sitio, tienes cuatro opciones:

1. Cambiar la versión en el panel. Muchos paneles de hosting permiten elegir la versión de PHP por dominio. Si en la lista ya hay una versión con la corrección, cambia el sitio a esa versión y compruébalo en Salud del sitio.
2. Abrir una incidencia con el hosting. Escribe al soporte técnico con los números CVE-2026-109618 y CVE-2026-109619 y pregunta cuándo recibirá el servidor PHP 8.2.35, 8.3.36, 8.4.27 u 8.5.12, o un paquete con esas correcciones.
3. Copia de seguridad antes del cambio. Pasar a una rama más reciente de PHP puede inutilizar un plugin o un tema antiguo. Una copia de los archivos y de la base de datos de antes del cambio acorta la vuelta a un sitio que funcione.
4. Desconectar el sitio hasta la actualización. Si PHP no se puede actualizar pronto, desconecta el sitio o muestra en su lugar una página estática de mantenimiento servida sin PHP. Nota nuestra: un plugin de modo mantenimiento de WordPress no basta, porque la petición sigue llegando a PHP. John Mueller, de Google, escribió el 21 de octubre: “Si estás desconectando sitios PHP para ganar tiempo y ocuparte de actualizaciones no planificadas, usa HTTP 503 en lugar de dejar que las respuestas agoten el tiempo de espera o devuelvan 404 o 500. Puedes hacerlo fuera de PHP, apuntar el DNS a otro sitio o usar una CDN.” (traducción propia, John Mueller, Bluesky). La página de mantenimiento con código 503 la sirve entonces el servidor web, la CDN u otro servidor tras un cambio de DNS, sin PHP, porque una página de mantenimiento con código 200, los tiempos de espera agotados, un 404 o un 500 pueden perjudicar la indexación. Google Search Central recomienda 503 cuando hay que desactivar un sitio con urgencia durante 1 o 2 días, una página de inicio indexable con código 200 para una pausa más larga, y desaconseja devolver 503 para robots.txt (Google Search Central).

WordPress.org escribió el 21 de octubre que los fallos no son específicos de WordPress y que no hace falta ni está prevista ninguna actualización de WordPress (WordPress.org). La misma entrada aconseja a quien gestiona su propio servidor con PHP anterior a 8.2 que valore desconectarlo mientras prepara la actualización, y remite al NCSC británico. El NCSC recomienda valorar desconectar el sistema hasta que esté protegido por completo si las medidas temporales no se pueden aplicar con suficiente rapidez (NCSC). CERT Polska recomendó ya antes de la publicación desactivar temporalmente los servicios PHP accesibles desde Internet (CERT Polska, 195/2026) e indica sus propios valores para php.ini en el aviso 196/2026. Patchstack da el mismo consejo para sitios de alto riesgo y advierte contra plugins de “corrección” no oficiales y fragmentos de código copiados, que “no están verificados y pueden romper tu sitio” (traducción propia, Patchstack). Un plugin se ejecuta dentro de PHP, así que no puede corregir un fallo del propio PHP.

php.net describe ajustes temporales del servidor para los administradores que no pueden actualizar PHP de inmediato. Incluyen, entre otros, límites de tamaño de las peticiones y la desactivación del seguimiento del progreso de subida de archivos en la sesión. Estos ajustes solo funcionan a nivel de configuración del servidor: php.net advierte que, para el ajuste de sesión, no bastan ini_set() ni un archivo .user.ini en el directorio del sitio. El aviso subraya también que ninguno de estos ajustes hace segura una instalación:

Aunque solo una actualización es una solución completa, las siguientes medidas reducen la exposición a vías de ataque concretas, pero no hacen segura una instalación.

(traducción propia, php.net, aviso de seguridad del 21 de octubre de 2026)

Como medida temporal y parcial, Calif indica session.upload_progress.enabled=0 junto con memory_limit=-1 para PHP-FPM y solo memory_limit=-1 para mod_php, y advierte de que el valor -1 elimina el límite de memoria de PHP, lo que aumenta el riesgo de que la memoria se agote (Calif).

php.net recomienda además eliminar ajustes de PHP no válidos u obsoletos aplicados en cada petición que generen avisos antes de la inicialización, y ocultar los avisos con error_reporting, display_errors o @ no ayuda. Ejemplo nuestro, no de php.net: desde PHP 8.3 todos los ajustes INI assert.* están obsoletos, así que en PHP 8.3 y versiones posteriores revisa .htaccess, los pools de FPM y php.ini en busca de entradas assert.* que hayan quedado, por ejemplo php_value assert.active.

Hemos reunido los detalles de estos ajustes para el administrador del servidor en la sección sobre la versión crítica de PHP de nuestra guía de seguridad para WordPress.

Si el tráfico del sitio pasa por Cloudflare (nube naranja en el registro DNS), hay una capa adicional. Según Cloudflare, desde las 05:02 del 21 de octubre de 2026, hora peninsular (03:02 UTC), los clientes con el WAF gratuito o de pago quedaron protegidos contra PHP2Shell por defecto, también en el plan Free, y en los planes Pro, Business y Enterprise conviene comprobar que el Managed Ruleset está desplegado en modo de bloqueo (Cloudflare). Patchstack matiza que estas reglas solo ayudan si el servidor acepta tráfico únicamente de Cloudflare (Patchstack). Si el servidor responde a cualquiera, una petición enviada directamente a su dirección IP esquiva el WAF. Cloudflare indica además que observó tráfico de ataque contra sus clientes antes de la publicación oficial, después de que la vulnerabilidad se filtrara, y atacantes que modificaban la carga del ataque para esquivar las reglas. La cronología de Patchstack recoge a las 07:34 UTC “varios incidentes de explotación activa notificados a Patchstack por socios de hosting” (traducción propia, Patchstack), mientras que Huntress escribió que no había visto explotación entre sus socios hasta las 10:00, hora de la costa este de EE. UU. (14:00 UTC), del 21 de octubre (Huntress). La propia Cloudflare presenta el WAF como una capa adicional de defensa y recomienda actualizar PHP de todos modos, y limitar las subidas de archivos y su tamaño tampoco sustituye a la corrección.

#Cómo detectar un intento de ataque en los registros del servidor

Wiz advierte de que los errores actúan por debajo de la capa de aplicación, así que los registros de WordPress pueden mostrar poco. Hasta la actualización, conviene buscar tres señales en los registros del servidor (Wiz):

• peticiones multipart inusuales seguidas de errores por superar el límite de memoria o de respuestas HTTP 500 repetidas,
• cookies PHPSESSID inesperadamente grandes o malformadas en las respuestas del servidor,
• reinicios sin explicación de los procesos de trabajo de PHP.

Estas señales indican por dónde empezar a revisar. Que no aparezcan no significa que no haya habido un ataque, y que aparezcan no sustituye a la actualización.

#¿Hay que cambiar las contraseñas después de la actualización?

El aviso de php.net no exige cambiar contraseñas. Es una recomendación nuestra, basada en la conclusión de Wiz: el fallo permite leer la memoria del proceso PHP, donde puede haber contraseñas, tokens y claves de API de otras peticiones (Wiz). Un sitio que funcionó durante un tiempo con una versión vulnerable puede haber expuesto un secreto así sin dejar rastro en el escritorio de WordPress.

Los secretos se cambian solo después de actualizar PHP, porque una contraseña nueva establecida en un servidor sin parchear puede filtrarse por la misma vía que la antigua.

Qué cambiar:

• Las claves y las sales de wp-config.php. El generador oficial de WordPress.org crea un nuevo juego de las ocho constantes. Tras el cambio, se cierra la sesión de todos los usuarios conectados.
• La contraseña de la base de datos. Cámbiala en el panel del hosting y escribe la nueva en wp-config.php como DB_PASSWORD.
• Las contraseñas de las cuentas de administrador y de otras cuentas con permisos de edición.
• Las claves de API: claves de la REST API de WooCommerce, claves de las pasarelas de pago, credenciales SMTP y tokens de servicios externos guardados en los ajustes de los plugins.

#Qué pasa con PHP 7.4, 8.0 y 8.1

El proyecto PHP ya no publica correcciones para PHP 8.1 y anteriores. El aviso de php.net indica dos caminos: algunas distribuciones y proveedores LTS ofrecen correcciones adaptadas, y el resto debería pasar a una versión con soporte. Dada la gravedad de los fallos, el equipo de seguridad de PHP publicó parches mínimos de código fuente para PHP 7.4, 8.0 y 8.1, pensados para quien compila PHP desde el código fuente o no tiene acceso a un proveedor LTS (php.net).

Si tu sitio está en un hosting compartido, los parches de código fuente no cambian nada, porque en un servidor así quien compila e instala PHP es el hosting. La opción real es pasar a PHP 8.3, 8.4 u 8.5 en la versión con la corrección. PHP 8.2 también recibió la corrección, pero su soporte de seguridad termina el 31 de diciembre de 2026 (php.net), así que elegir 8.2 supone otro cambio dentro de dos meses.

La tabla de compatibilidad entre versiones de WordPress y PHP está en el artículo actualizar WordPress con seguridad. Si un tema o plugin antiguo impide pasar a un PHP más reciente, el plan de migración está en la guía para modernizar bases de código WordPress heredadas. Si una tienda WooCommerce dejó de aceptar pedidos o muestra errores críticos tras cambiar la versión de PHP, te ayudará el sprint de rescate de WooCommerce. La revisión de la configuración del servidor, de la versión de PHP y de las cuentas tras un incidente forma parte de la auditoría de seguridad de WordPress.

#Lista de comprobación para propietarios de sitios WordPress y tiendas WooCommerce

Situación a 21 de octubre de 2026, hacia las 17:30 UTC, según el aviso de php.net, las entradas de GitHub Security Advisories, las publicaciones de Calif y Wiz Research y los avisos de Ubuntu, Debian, WordPress.org, NCSC, CERT Polska, Patchstack y Huntress.