PHP2Shell: qué es la vulnerabilidad crítica de PHP y qué tiene que hacer tu empresa

PHP2Shell es el nombre de dos vulnerabilidades críticas de PHP, el lenguaje con el que funcionan WordPress y la mayoría de webs. Permiten a un atacante ejecutar código en el servidor con una sola petición y sin contraseña. Se corrigen actualizando PHP, no WordPress ni los plugins. Aquí tienes qué versiones están a salvo, qué hacer si usas una antigua y cómo saber si ya te han atacado.

Qué es PHP2Shell

PHP2Shell son dos fallos distintos del propio PHP, registrados como CVE-2026-109618 y CVE-2026-109619. Los descubrieron, por separado, la empresa de seguridad Calif y Wiz, y PHP publicó la corrección el 21 de octubre de 2026 (CyberScoop). Explicados sin tecnicismos (watchTowr):

• CVE-2026-109618: si PHP se queda sin memoria a mitad de preparar una petición, deja datos a medio construir y después los usa como si fueran buenos.
• CVE-2026-109619: datos de una petición siguen vivos cuando ya no deberían, y la siguiente petición que atiende el mismo proceso los reutiliza.

En los dos casos, el resultado es el mismo: alguien desde internet puede ejecutar sus propias órdenes en tu servidor, sin usuario ni contraseña.

Lo que lo hace tan serio es dónde está el fallo. No es un plugin ni una aplicación concreta: es el motor que las ejecuta. PHP mueve entre el 70 % y el 80 % de las webs cuyo lenguaje de servidor se conoce (CyberScoop), y Wiz demostró el ataque contra WordPress, Drupal y Joomla (Huntress).

A quién afecta PHP2Shell

A cualquier servidor que sirva páginas web con PHP, se instale como se instale: PHP-FPM, Apache con mod_php, php-cgi, LiteSpeed o FrankenPHP. El riesgo más alto es con mod_php (Centro Canadiense de Ciberseguridad). En una empresa, eso suele incluir:

• La web corporativa, sobre todo si está hecha con WordPress, Drupal o Joomla.
• La tienda online.
• La intranet y los portales de clientes, proveedores o empleados.
• El correo web y herramientas de administración como phpMyAdmin.
• Aplicaciones a medida hechas con Laravel o Symfony.
• Equipos y programas de terceros que llevan PHP dentro, aunque no lo veas.

Si tu web está en un hosting compartido, la corrección depende de tu proveedor, pero la versión de PHP que usa tu web la sueles elegir tú en el panel. Si ahí pone 8.1 o anterior, estás expuesto aunque el proveedor haya actualizado todo lo demás.

Qué versiones de PHP corrigen PHP2Shell

Las corregidas son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12 (Centro Canadiense de Ciberseguridad). Las ramas antiguas no tienen versión oficial (watchTowr):

Rama de PHP	Recibe parches hasta	Versión que corrige el fallo
8.5	31-12-2029	8.5.12
8.4	31-12-2028	8.4.27
8.3	31-12-2027	8.3.36
8.2	31-12-2026 (php.net)	8.2.35
8.1, 8.0 y 7.4	Sin soporte	Sin versión oficial: solo parches para compilar o los de tu distribución
7.3 y anteriores, PHP 5 incluido	Sin soporte	Sin corrección

Las distribuciones de Linux y los paneles de hosting recibieron la corrección antes que nadie, pero la van publicando a distinto ritmo. Este era el estado a 21 y 22 de octubre (Tanium):

Plataforma	Estado
Ubuntu 22.04, 24.04, 26.04 y 26.10	Corregido
Ubuntu 20.04	Solo con Ubuntu Pro
Debian 12 y 13	Corregido
Plesk para Linux	Corregido
Plesk para Windows	Pendiente
cPanel (EasyApache 4)	Corregido en la versión 25.91
Red Hat Enterprise Linux 8, 9 y 10	Pendiente
Imágenes oficiales de Docker	Corregido en las etiquetas 8.5.12, 8.4.27, 8.3.36 y 8.2.35

Cambia cada día, así que confírmalo con tu proveedor antes de dar nada por hecho. Y una versión de Ubuntu o Debian que ya no tiene soporte no va a recibir la corrección: en ese caso hay que cambiar de versión de PHP o de sistema.

Qué hacer hoy, paso a paso

Empieza por lo que da a internet. Estos son los pasos, en orden:

1. Haz inventarioQué servidores y aplicaciones usan PHP. Incluye los equipos y programas de otros fabricantes que lo llevan dentro (Centro Canadiense de Ciberseguridad).
2. Comprueba la versión que usa la webMírala en el panel del hosting o con una página phpinfo() que borres después. Ojo con el comando php -v: enseña la versión de la consola, que en muchos servidores no es la misma que usa la web.
3. Actualiza y reiniciaSube a 8.2.35, 8.3.36, 8.4.27 o 8.5.12 y reinicia PHP-FPM o el servidor web para que cargue la versión nueva (Tanium). Si estás en 8.2, aprovecha para pasar a 8.3 o 8.4: la 8.2 deja de recibir parches el 31 de diciembre.
4. Si usas PHP 8.1 o anteriorNo hay versión oficial que instalar. Cambia a 8.3 o 8.4 y prueba la web, porque es un salto grande y algún plugin o aplicación antigua puede dejar de funcionar.
5. Revisa si ya te han atacadoCon los registros desde el 17 de octubre. Te explicamos qué buscar en el siguiente apartado.

Si hay algo que no puedes actualizar hoy, reduce el riesgo mientras tanto:

• Sácalo de internet o déjalo solo accesible por VPN. Es lo que recomienda el centro de ciberseguridad del Reino Unido para lo que no se pueda corregir ya (Help Net Security).
• Ponlo detrás de un firewall de aplicaciones web con reglas para PHP2Shell. Cloudflare ya las ha publicado para todos sus clientes (Help Net Security).
• Activa las firmas de tu firewall. Sophos publicó el 22 de octubre firmas IPS para su firewall y su protección de equipos, y confirma que ninguno de sus productos está afectado (Sophos).
• En versiones sin soporte, desactiva session.upload_progress.enabled en php.ini. Corta los ataques conocidos (Huntress), aunque PHP avisa de que ningún cambio de configuración lo arregla del todo (watchTowr).

Todo esto ayuda, pero no sustituye a actualizar. Y la próxima vez llegarás antes si ya sabes qué servidores tienes y en qué versión está cada uno: es lo que resuelve la gestión de vulnerabilidades.

Cómo saber si ya te han atacado

Como hubo intentos antes del aviso, revisa los registros del servidor desde el 17 de octubre. Estas son las señales que recomienda buscar Huntress (Huntress):

Si ves alguna, aísla el servidor y guarda los registros antes de tocar nada: si actualizas y reinicias primero, puedes borrar las pruebas de lo que ha pasado.

Revisar esto a mano en cada servidor lleva tiempo. Un EDR instalado en el servidor detecta este tipo de comportamiento en el momento; lo explicamos en EDR, XDR y MDR. Y si quieres saber qué se ve de tu empresa desde fuera, eso lo responde un pentesting.

Si te aplica el ENS o NIS2

Un caso como este es lo primero que mira un auditor: cuándo te enteraste, qué servidores estaban afectados y cuándo los actualizaste. El ENS lo pide en la medida op.exp.4, de mantenimiento y actualizaciones de seguridad (Real Decreto 311/2022), y NIS2 incluye la gestión de vulnerabilidades entre las medidas de su artículo 21.2.e (Directiva NIS2).

Deja constancia de lo que hagas estos días: el inventario, las versiones antes y después, y la revisión de registros. Te servirá en la próxima auditoría. Si te toca, lo explicamos en la guía de certificación ENS y en NIS2 en España, que todavía no se ha traspuesto.

Preguntas frecuentes