El 21 de octubre de 2026, el equipo de PHP publicó parches de emergencia para dos vulnerabilidades críticas que, combinadas, se han bautizado como «PHP2Shell». Permiten ejecutar código de forma remota y sin autenticación en potencialmente millones de servidores web. Si administras una web —propia o de un cliente—, esto te afecta. Vamos a explicarte sin humo qué es el fallo, cómo funciona por dentro, a quién afecta y, sobre todo, qué tienes que hacer para estar protegido.
Qué es PHP2Shell
PHP mueve una parte enorme de internet: WordPress, Drupal, Magento, Laravel y miles de aplicaciones a medida. PHP2Shell es el nombre con el que se ha popularizado un conjunto de dos fallos en el propio núcleo (core) de PHP: CVE-2026-109618 y CVE-2026-109619.
Lo preocupante es que, combinados, permiten RCE (Remote Code Execution, ejecución remota de código) sin necesidad de usuario ni contraseña. Es decir: un atacante que únicamente pueda enviar peticiones web a tu servidor podría, en el peor de los casos, ejecutar comandos en él. De ahí el «2Shell»: de una simple petición web… a una shell (consola) en tu servidor.
Gravedad: 9,2 sobre 10 (CVSS v4.0, según el propio equipo de PHP). La firma de seguridad watchTowr lo puntúa incluso con un 10,0. Tanto CISA (EE. UU.) como el NCSC británico pidieron parchear de inmediato.
Las dos vulnerabilidades, por dentro
Para entender por qué es tan serio conviene mirar qué falla en cada una. Lo explicamos a nivel conceptual: aquí no hay exploits, solo comprensión.
CVE-2026-109618 — corrupción de memoria al quedarse sin memoria
Este fallo se produce durante el manejo de situaciones de falta de memoria (out-of-memory). Cuando PHP no puede reservar más memoria, ejecuta una rutina de salida controlada para abortar la petición de forma ordenada. El problema es que, en ese camino y bajo ciertas condiciones, se corrompe la memoria interna del intérprete. Un atacante que logre provocar esa condición de falta de memoria de forma controlada puede empezar a manipular estructuras internas de PHP — el primer paso para tomar el control.
CVE-2026-109619 — use-after-free entre peticiones
Un use-after-free ocurre cuando un programa sigue usando un puntero a memoria que ya ha sido liberada. Aquí el fallo está ligado a estado de la petición que no se limpia correctamente y persiste de una petición a la siguiente.
Esto es clave en los SAPIs persistentes (como PHP-FPM o mod_php), donde un mismo proceso atiende muchas peticiones seguidas. Si el estado de una petición «contamina» la siguiente, se puede acabar usando una referencia a memoria ya liberada que el atacante consigue controlar. Combinado con el fallo anterior, es lo que convierte el riesgo en un RCE fiable en determinados entornos.
¿A quién afecta? La clave está en el SAPI
PHP no se ejecuta de una única manera: lo hace a través de un SAPI (Server API), la pieza que conecta PHP con el servidor web. Estos son los afectados:
- mod_php (Apache): PHP embebido en el propio proceso de Apache. Es el que PHP considera de mayor riesgo.
- PHP-FPM: el más usado hoy (Nginx + PHP-FPM, y también con Apache). Procesos persistentes que atienden muchas peticiones.
- php-cgi: el modo CGI clásico.
- FrankenPHP y LiteSpeed: entornos de ejecución modernos.
En la práctica: casi cualquier servidor que ejecute PHP para atender peticiones web está en el punto de mira.
Estado real: ¿hay exploits? ¿hay ataques?
Sí, ya existen pruebas de concepto (PoC) públicas. La buena noticia, según investigadores de Rapid7, es que cada PoC funciona de momento solo contra una combinación concreta de sistema operativo + versión de PHP + servidor web, y ninguna es todavía «universalmente fiable». La mala: Cloudflare ya ha detectado tráfico de ataque buscando estos fallos. Traducción: la ventana para parchear antes de que los exploits maduren es ahora.
¿Estoy afectado? Comprueba tu versión de PHP
Lo primero es saber qué versión de PHP ejecutas. Tienes varias formas:
Por SSH / terminal:
php -vCon un archivo temporal (crea info.php en tu web, míralo y bórralo después — no lo dejes público):
<?php phpinfo(); ?>En el panel del hosting (Plesk, cPanel…): busca la sección «PHP» o «Configuración de PHP» de tu dominio.
Las versiones corregidas son:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Si tu versión es igual o superior dentro de su rama (por ejemplo, 8.3.36 o más en la rama 8.3), estás parcheado. PHP 8.1 y anteriores ya no tienen soporte: si sigues ahí, no vas a recibir parche — toca migrar a una rama soportada.
Qué hacer: protégete paso a paso
1. Actualiza PHP (lo más importante)
El arreglo está en PHP, no en tu aplicación. Actualiza a la versión parcheada de tu rama. Si gestionas tu propio servidor, actualiza los paquetes de PHP y reinicia el servicio (PHP-FPM / Apache). Algunas distribuciones publican backports del parche a ramas antiguas: si estás en una, consulta con tu distribución.
2. Hosting compartido: confírmalo con tu proveedor
En hosting compartido no controlas el PHP del sistema. Haz dos cosas: (a) en el panel, selecciona una versión de PHP parcheada para tu dominio; y (b) pregunta a tu proveedor si ya ha actualizado los paquetes de PHP del servidor. Los buenos hostings suelen parchear rápido tras una RCE crítica.
3. OJO: actualizar WordPress / Drupal / Magento NO basta
Es el error más común. Mucha gente cree que con tener su CMS al día ya está cubierta. No. El fallo está en el intérprete de PHP del servidor, por debajo de tu CMS. Puedes tener WordPress perfectamente actualizado y seguir siendo vulnerable si el PHP del servidor no está parcheado. Actualiza ambos: el CMS por otras razones, y el PHP por esta.
4. Mitigaciones temporales (si no puedes parchear ya)
- El NCSC llegó a recomendar sacar de línea los sistemas afectados que no se puedan corregir de inmediato.
- Un WAF (Cloudflare, etc.) puede filtrar algunos intentos, pero no es una solución: es una red de contención mientras parcheas.
- Reduce la superficie: desactiva SAPIs y endpoints que no utilices.
La lección de fondo (para quien desarrolla)
- El stack importa tanto como tu código. Una vulnerabilidad en el intérprete afecta a todas tus aplicaciones a la vez.
- Mantén actualizado el runtime, no solo el framework. Composer al día está muy bien, pero el PHP de debajo también cuenta.
- Conoce tu SAPI. Saber si usas mod_php, FPM o CGI te ayuda a evaluar el riesgo real y a priorizar.
- Ten un plan de parcheo rápido. El tiempo entre la publicación de un fallo y un exploit fiable se acorta cada vez más.
En resumen (TL;DR)
- PHP2Shell = dos fallos críticos del core de PHP (
CVE-2026-109618yCVE-2026-109619) → RCE sin autenticación. - Parcheado el 21/10/2026 en PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35.
- Comprueba tu versión (
php -vo el panel del hosting) y actualiza ya. - Actualizar el CMS no basta: el parche va a nivel de servidor (PHP).
Fuentes: avisos oficiales de CISA y del NCSC (Reino Unido), e informes de Rapid7, Qualys y Help Net Security. Al tratarse de un fallo reciente, algunos detalles técnicos pueden matizarse en los próximos días; verifica siempre la versión parcheada en la web oficial de PHP y con tu proveedor de hosting.
