¿Mi sitio de WordPress está afectado por PHP2Shell?

Muy probablemente, salvo que tu hosting ya haya instalado PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35 o una versión del proveedor con la corrección. Los fallos están en PHP mismo, así que todo sitio de WordPress en una versión sin parchear está expuesto, y los investigadores demostraron el ataque contra WordPress, Drupal y Joomla.

¿Un plugin de seguridad de WordPress me protege?

No. En Apache con mod_php el ataque demostrado ocurre antes de que se ejecute el código de la aplicación, así que un plugin dentro de WordPress nunca lo ve. Un firewall de aplicaciones en el borde, como las reglas que Cloudflare activó el 21 de octubre, puede bloquear patrones conocidos, pero solo actualizar PHP corrige el fallo.

Mi servidor muestra un número de PHP más bajo después de actualizar. ¿Sigue vulnerable?

No necesariamente. Ubuntu y Red Hat suelen aplicar la corrección sin cambiar la versión original; por ejemplo, Ubuntu 24.04 la incluye como 8.3.6-0ubuntu0.24.04.13. Compara la versión del paquete con el aviso de seguridad de tu distribución en lugar del número que muestra php -v.

PHP2Shell CVE-2026-109618: cómo revisar y corregir PHP

El 21 de octubre de 2026 el proyecto PHP publicó un aviso de seguridad titulado "Critical remote code execution vulnerabilities, update now". Dos fallos, CVE-2026-109618 y CVE-2026-109619, ya conocidos como PHP2Shell, pueden permitir que un atacante ejecute código en un servidor web que usa PHP sin iniciar sesión. Si tu negocio usa WordPress, WooCommerce, Joomla, Drupal, Laravel o casi cualquier sitio en un hosting con cPanel, funciona con PHP, así que te toca revisarlo hoy.

No es un fallo teórico. Los investigadores de Wiz, que ayudaron a reportarlo, demostraron ejecución de código sin autenticación contra WordPress, Drupal y Joomla en entornos de prueba, y dicen que las versiones afectadas se remontan a PHP 5.4. Cloudflare escribió el 21 de octubre que la vulnerabilidad "se filtró antes de la fecha oficial de publicación" y que "observó tráfico de ataque dirigido a nuestros clientes" (traducción nuestra).

Qué se corrigió, en palabras simples

Los dos fallos tienen que ver con memoria que PHP cree que está en buen estado cuando no lo está. Un atacante que puede enviar peticiones web a tu servidor puede llevar a PHP a usar esa memoria y, desde ahí, a ejecutar su propio código.

CVE-2026-109618, "RCE via OOM corruption" (aviso de GitHub GHSA-w8hw-w9fx-j79w). Cuando PHP se queda sin memoria a mitad de preparar una petición, la limpieza posterior puede tratar datos a medio inicializar como válidos. El aviso describe varias formas en que una subida de archivos (multipart) manipulada puede llevar a PHP a ese punto sin salirse de sus límites normales de tamaño.
CVE-2026-109619, "RCE via stale global state" (aviso de GitHub GHSA-6wmf-4rv5-p3rp). Parte del estado de una petición puede sobrevivir a la memoria que lo respalda, y la siguiente petición atendida por el mismo proceso de PHP puede usarlo antes de que PHP lo reinicie.

El proyecto PHP califica ambos como críticos, CVSS v4 9.2 de 10. Según el propio aviso, el riesgo alcanza a "todas las instalaciones de PHP que atienden peticiones web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed" (traducción nuestra). Considera el riesgo más alto en Apache con mod_php, donde ya existe un exploit demostrado en el que una petición sin autenticación dispara el ataque antes de que se ejecute el código de tu aplicación. Ese detalle importa: un plugin de seguridad dentro de WordPress no puede ver ni frenar un ataque que ocurre antes de que WordPress arranque. PHP-FPM es más difícil de atacar, pero tampoco es seguro: el segundo aviso confirma ejecución de código también en FPM.

Aviso de seguridad de GitHub GHSA-w8hw-w9fx-j79w de php-src, calificado Critical 9.2, con las versiones afectadas por debajo de 8.2.35, 8.3.36, 8.4.27 y 8.5.12 — El aviso de GitHub para CVE-2026-109618 muestra las versiones afectadas, las corregidas y la puntuación CVSS v4. Captura: github.com/php/php-src.

Qué versión de PHP lo corrige

Busca la rama que usas (los dos primeros números, por ejemplo 8.3) y compárala con la versión corregida de esa rama. Una versión por debajo del número de la columna del medio es vulnerable, salvo que tu proveedor haya publicado su propia versión parcheada.

Tu rama	Corregido en	Qué hacer
PHP 8.5	`8.5.12`	Actualizar. Medida temporal extra solo para 8.5 más abajo
PHP 8.4	`8.4.27`	Actualizar
PHP 8.3	`8.3.36`	Actualizar
PHP 8.2	`8.2.35`	Actualizar. 8.2 llega a fin de soporte el 31 de diciembre de 2026, así que planea 8.3 u 8.4
PHP 8.1, 8.0, 7.4	Sin versión en php.net	Solo lo corrige un parche del proveedor o compilar desde el código fuente. Pasa a una rama con soporte
PHP 7.3 hasta 5.4	Nada publicado	Afectadas según Wiz. Trátalas como expuestas y actualiza

PHP 8.1 y anteriores ya no tienen soporte oficial. Por la gravedad, el equipo de seguridad de PHP publicó parches mínimos en código fuente para 7.4, 8.0 y 8.1, pero sirven a quien compila PHP por su cuenta. En un plan de hosting solo ayudan si tu proveedor los compila y los instala.

Cómo saber qué versión de PHP usa realmente tu sitio

Aquí ocurren la mayoría de los errores. Ejecutar php -v por SSH te dice la versión de PHP de la línea de comandos, que muchas veces no es la que atiende tu sitio web. Un servidor de hosting puede tener una docena de versiones de PHP instaladas a la vez, y cada sitio elige una en su panel o en su archivo .htaccess. En un servidor compartido que revisamos el 21 de octubre, la versión corregida 8.3.36 ya estaba instalada, y el sitio alojado ahí seguía fijado en PHP 7.4.

Tres formas de ver la versión que atiende a tus visitantes, de la más fácil a la más confiable:

WordPress: ve a Herramientas, luego Salud del sitio, pestaña Información, y abre Servidor. Ahí aparece la versión de PHP y la interfaz del servidor (FPM, LiteSpeed, módulo de Apache).
Tu panel de hosting: en cPanel busca MultiPHP Manager o Select PHP Version; en hPanel de Hostinger busca Configuración de PHP. Anota la rama y la versión exacta si aparece.
Un archivo de prueba de un minuto: sube un archivo con un nombre al azar, ábrelo en el navegador y bórralo de inmediato.

<?php
// guárdalo como check-7f3a.php en la raíz del sitio, ábrelo y luego BÓRRALO
echo PHP_VERSION, ' ', PHP_SAPI;

Para que la comparación sea automática, este pequeño script indica si una versión está en la versión corregida de su rama o por encima. Lo corrimos contra las imágenes oficiales de Docker el 21 de octubre: en ese momento la etiqueta flotante php:8.4-cli todavía traía 8.4.26, así que "la última" aún no estaba parcheada.

<?php
$fixed = ['8.2' => '8.2.35', '8.3' => '8.3.36', '8.4' => '8.4.27', '8.5' => '8.5.12'];
$branch = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;
echo 'PHP ', PHP_VERSION, ' (', PHP_SAPI, '): ';
if (!isset($fixed[$branch])) {
    echo "branch $branch gets no php.net release; only a vendor backport fixes it\n";
} elseif (version_compare(PHP_VERSION, $fixed[$branch], '>=')) {
    echo "at or above {$fixed[$branch]}, patched\n";
} else {
    echo "below {$fixed[$branch]}, VULNERABLE unless your vendor backported the fix\n";
}

Salida de terminal del 21 de octubre de 2026: PHP 8.3.35 y 8.4.26 aparecen como vulnerables y PHP 8.1.34 como dependiente de un parche del proveedor — Nuestra revisión contra las imágenes oficiales de Docker el 21 de octubre de 2026. Salida real, con formato para lectura.

Una advertencia sobre los números de versión: las distribuciones de Linux suelen parchear PHP sin cambiar el número de versión original. Ubuntu 24.04, por ejemplo, incluye la corrección en el paquete 8.3.6-0ubuntu0.24.04.13 (USN-8948-1), así que un servidor Ubuntu ya parcheado sigue mostrando PHP 8.3.6. En esos sistemas revisa la versión del paquete en el aviso de seguridad de tu distribución en lugar de confiar solo en php -v.

Cómo actualizar, según dónde vive tu sitio

Hosting compartido (cPanel, CloudLinux, Hostinger, Bluehost, Namecheap y similares)

Aquí no puedes parchear PHP por tu cuenta. El proveedor recompila sus paquetes de PHP y tu sitio los toma. Lo que sí puedes hacer:

Asegúrate de que el sitio esté en una rama con soporte, 8.2 o superior, idealmente 8.3 u 8.4. Si está en 7.4 u 8.1, ese es el riesgo más grande.
Revisa si el sitio está detrás de Cloudflare. Cloudflare dice que activó reglas de WAF para estos fallos desde las 03:02 UTC del 21 de octubre en todos los planes con el WAF activo, incluido el gratuito. Eso bloquea patrones de ataque conocidos en el borde, pero es un filtro, no una corrección, y no sirve para el tráfico que llega directo al servidor.
En planes de pago de Cloudflare (Pro, Business, Enterprise), confirma que el Managed Ruleset esté en modo bloqueo.
Quita del .htaccess las líneas php_value y php_flag inválidas u obsoletas. El aviso de CVE-2026-109619 las menciona como un disparador temprano en Apache con mod_php.
Pregunta por escrito al soporte del hosting si la actualización de seguridad de PHP del 21 de octubre (CVE-2026-109618 y CVE-2026-109619) ya está instalada para tu rama, y cuándo.
Vuelve a revisar la versión cuando lo confirmen, con alguno de los métodos de arriba.

Tu propio servidor o VPS

El aviso dice que las distribuciones de Linux y los proveedores de soporte extendido recibieron los parches con anticipación. Este era el estado cuando revisamos la tarde del 21 de octubre (UTC), así que confírmalo en el sistema de seguimiento de tu distribución:

Ubuntu: corregido en 22.04 (php8.1), 24.04, 26.04 y 26.10 (USN-8948-1 y USN-8948-2); 20.04 y anteriores tienen la corrección con Ubuntu Pro (ESM).
Debian: trixie corregido en php8.4 8.4.27-1~deb13u1 (DSA-6574-1) y bookworm en php8.2 8.2.35-1~deb12u1 (DLA-4848-1).
Red Hat Enterprise Linux: calificado como Important, sin erratas publicadas todavía. Amazon Linux 2 y 2023: corrección pendiente.
El repositorio de Ondřej Surý (packages.sury.org, muy usado en servidores Debian y Ubuntu): versiones corregidas de 8.2 a 8.5, y paquetes 7.4, 8.0 y 8.1 recompilados con el parche.

Luego instala las actualizaciones: apt update && apt install --only-upgrade 'php*' en Debian y Ubuntu, dnf upgrade 'php*' en sistemas de la familia RHEL. Después de instalar, reinicia todos los procesos de PHP, no solo el servidor web: systemctl restart php8.3-fpm (usa tu versión) y luego Apache o LiteSpeed. Un proceso de FPM que sigue corriendo mantiene el código viejo en memoria.

Si instalas PHP desde el repositorio de Remi, mantenido por voluntarios (rpms.remirepo.net), toma en cuenta la advertencia del aviso: ese repositorio no tendrá actualizaciones el día de la publicación, y el equipo de PHP recomienda pasar a los paquetes de la distribución o compilar desde el código fuente para poder parchear de inmediato.

Docker y contenedores

Las imágenes oficiales de Docker recibieron etiquetas exactas para las versiones corregidas la tarde del 21 de octubre, pero las etiquetas flotantes se quedaron atrás: cuando revisamos, php:8.4-cli todavía traía 8.4.26. Fija y recompila sobre la etiqueta exacta corregida (por ejemplo php:8.3.36-fpm), y vuelve a desplegar para que ningún contenedor viejo siga atendiendo tráfico. Revisa con docker run --rm <imagen> php -v antes de desplegar.

La sección How to update del aviso de seguridad de PHP en php.net, con la advertencia sobre el repositorio de Remi y los parches para PHP 7.4, 8.0 y 8.1 — Las instrucciones de actualización y las primeras medidas temporales del aviso oficial (en inglés). Captura: archivo de noticias de php.net.

Si no puedes actualizar hoy: las medidas temporales y sus límites

El proyecto PHP es claro en que estas medidas "reducen la exposición a ciertas rutas de ataque, pero no hacen que una instalación sea segura" (traducción nuestra). Úsalas solo para ganar horas o días mientras programas la actualización real.

Para CVE-2026-109618, configura memory_limit=-1 donde las aplicaciones no puedan cambiarlo, usa un post_max_size bajo (8M si el sitio no recibe archivos, 32M si sí, con upload_max_filesize por debajo) y mantén los límites de memoria del contenedor o de cgroup como red de seguridad. No uses RLIMIT_AS ni RLIMIT_DATA en su lugar: el aviso dice que pueden causar justo el fallo de asignación que el ataque necesita. Para CVE-2026-109619, configura session.upload_progress.enabled=0 y reinicia todos los procesos; en PHP 8.5 configura también fatal_error_backtraces=0.

; php.ini (se aplica antes de procesar la petición)
session.upload_progress.enabled = 0
post_max_size = 8M        ; 32M si el sitio recibe archivos
; solo PHP 8.5:
fatal_error_backtraces = 0

En PHP-FPM, configura los mismos valores en el archivo del pool con las directivas de administrador, para que la aplicación no pueda cambiarlos:

; /etc/php/8.3/fpm/pool.d/www.conf (la ruta varía)
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[post_max_size] = 8M
php_admin_value[memory_limit] = -1

Los avisos de GitHub agregan algunas más para servidores que tú administras: bloquear las peticiones multipart en el proxy en sitios que nunca reciben archivos, bajar max_input_nesting_level y considerar pm.max_requests=1 en FPM para que ningún proceso atienda una segunda petición (cuesta rendimiento). Deja session.upload_progress apagado incluso después de parchear si nada lo usa.

Dos trampas. Primero, estas configuraciones deben aplicarse antes de que PHP procese la petición, así que ini_set() en tu código y los archivos .user.ini de FPM no cuentan. Segundo, ocultar errores con display_errors, error_reporting o el operador @ no sirve de nada contra estos fallos.

Señales de que alguien ya lo intentó

Parchear cierra la puerta, pero no te dice si alguien entró antes. El fallo se filtró antes de la publicación oficial, y Cloudflare reporta tráfico de ataque. Wiz recomienda buscar estas señales en tus registros:

Peticiones multipart (tipo subida de archivos) seguidas de errores de límite de memoria o respuestas HTTP 500 repetidas.
Cookies PHPSESSID demasiado grandes o malformadas en las respuestas.
Picos sin explicación en los reinicios de procesos de PHP.

Si las ves, o si el sitio estuvo accesible directamente antes de que lo parchearas, revisa también si hay cuentas de administrador nuevas, archivos PHP modificados fuera de tus despliegues normales y tareas programadas que no reconoces. En hosting compartido, los registros de errores del proveedor y el escaneo de archivos del plugin de seguridad son el punto de partida práctico. Wiz advierte que los fallos también pueden filtrar contenido de la memoria, así que si sospechas exposición, cambia las contraseñas de la base de datos, las claves de API y las salts de WordPress.

Lo que revisamos para nuestros clientes esta semana

Cuando un cliente nos pregunta por este aviso, recorremos la misma lista corta en cada sitio, porque la versión que muestra un panel y la versión que atiende las peticiones no siempre son la misma:

La rama y la versión exacta de PHP que usa cada sitio en la web, no solo en la línea de comandos.
Si el hosting o la distribución ya publicó la versión corregida, con la confirmación por escrito.
Sitios viejos fijados en 7.4 u 8.1 en el .htaccess o en el panel, que son los que más se olvidan.
Que los procesos de PHP-FPM y LiteSpeed se reiniciaron después de actualizar.
Respaldos recientes y restaurables antes de cualquier cambio de versión, porque pasar un tema viejo de 7.4 a 8.3 puede romper el diseño.

¿Quieres que revisemos o corrijamos tus sitios?

Si no tienes claro qué versión de PHP usa tu sitio, o la respuesta de tu hosting fue vaga, podemos hacer la revisión por ti y encargarnos de la actualización o del paso a una rama con soporte, con un respaldo previo. Escríbenos con la dirección de tu sitio: por correo a info@guanacostech.com o por WhatsApp. Trabajamos con pequeñas y medianas empresas en Norteamérica y Latinoamérica; puedes ver cómo funcionan nuestros proyectos en cómo trabajamos o leer sobre nuestra consultoría de nube y servidores para equipos pequeños.

PHP2Shell (CVE-2026-109618 y CVE-2026-109619): cómo revisar y corregir tus sitios en PHP