PHP2Shell (CVE-2026-109618/109619): qué hacer ahora

Resumen (actualizado el 23/10/2026): PHP2Shell es el nombre de dos fallos críticos en el propio PHP, CVE-2026-109618 y CVE-2026-109619, ambos con CVSS v4 9,2. Permiten ejecución remota de código sin autenticación y, en el caso de la 109619, fuga de memoria del proceso, que puede exponer contraseñas, tokens y claves de API de otras peticiones. Actualiza a 8.5.12, 8.4.27, 8.3.36 u 8.2.35. Después, rota los secretos: el parche cierra la puerta, pero no deshace lo que ya pudo haberse filtrado. Hubo intentos de explotación antes de la divulgación.

El martes 21 de octubre de 2026, el proyecto PHP publicó correcciones de emergencia para dos vulnerabilidades descubiertas por Wiz Research, Calif y OpenAI, en coordinación con el equipo de seguridad de PHP. El apodo lo resume: el camino va del intérprete PHP directamente a una shell en el servidor.

Este artículo es para quien necesita decidir rápido: CTOs, equipos de infraestructura, responsables de sitios WordPress y gestores de riesgo. Aquí no hay detalles de explotación, solo qué hacer, en qué orden y cómo demostrar que se hizo.

Qué ha pasado

Son dos fallos distintos en el núcleo de PHP, no en un plugin ni en un framework:

CVE-2026-109618 (corrupción por falta de memoria). La gestión de out-of-memory puede interrumpir PHP mientras los datos internos de la petición están solo parcialmente inicializados. La limpieza de la petición trata esos datos inválidos como válidos, y eso permite ejecutar código con los privilegios del usuario del servidor web.
CVE-2026-109619 (estado global obsoleto). Un estado interno de la petición puede sobrevivir después de liberarse su memoria (use-after-free en el heap). Una petición posterior atendida por el mismo worker puede usar ese estado antes de que se reinicialice. Resultado: fuga de memoria del proceso y ejecución remota de código sin autenticación.

Wiz demostró ejecución remota de código sin autenticación contra instalaciones de WordPress, Drupal y Joomla, además de lectura de memoria sensible del proceso. Según Help Net Security, la red de honeypots de Amazon registró un intento de explotación el 17 de octubre, cuatro días antes de la divulgación. El CTO de Cloudflare confirmó ataques iniciales, según BleepingComputer. A 23/10/2026 las CVE no figuraban en el catálogo KEV de CISA, pero eso no significa que el riesgo sea teórico: ya se han visto intentos.

Quién está más expuesto

Toda instalación de PHP que atiende peticiones web está afectada: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El mayor riesgo está en Apache con mod_php, donde el intérprete vive dentro del proceso del servidor web.

Versiones corregidas:

Rama	Versión corregida	Estado
8.5	8.5.12	Con soporte
8.4	8.4.27	Con soporte
8.3	8.3.36	Con soporte
8.2	8.2.35	Con soporte
8.1, 8.0, 7.4 y anteriores	Sin release oficial	Fuera de soporte; el proyecto publicó backports mínimos de código fuente para 7.4, 8.0 y 8.1, y algunas distribuciones aplican correcciones propias

Un detalle importante: en Debian, Ubuntu, RHEL y derivados, el paquete puede estar corregido sin que cambie el número de versión, porque la distribución hace backport del parche. Mirar solo el X-Powered-By o el php -v puede engañar en ambos sentidos. Revisa el changelog del paquete.

También están en una situación más delicada:

sitios con PHP 8.1 o anterior, que dependen de backports;
hosting compartido, donde no controlas cuándo se actualiza PHP;
servidores que guardan secretos en variables de entorno o en la memoria del proceso (casi todos).

Hazlo ahora: checklist en orden

Averigua la versión real en el servidor, no por la web. Ejecuta php -v y php-fpm -v (o el binario equivalente) en cada host. Nunca publiques un phpinfo() para comprobarlo.
Actualiza a 8.5.12, 8.4.27, 8.3.36 u 8.2.35. Si usas paquetes de la distribución, comprueba en el changelog que CVE-2026-109618 y CVE-2026-109619 figuran como corregidas.
Reinicia PHP-FPM, Apache y los workers. Un parche instalado con procesos antiguos en marcha no protege.
Si no puedes actualizar hoy, aplica las mitigaciones parciales recomendadas por el equipo de PHP (reducen la exposición, pero según el propio proyecto ninguna bloquea totalmente los ataques):
- Para la 109618: memory_limit=-1 mediante php_admin_value en la configuración de FPM o Apache; un post_max_size bajo (8M sin subidas, 32M con subidas); límites de memoria por contenedor o cgroup.
- Para la 109619: session.upload_progress.enabled=0; en PHP 8.5, fatal_error_backtraces=0; elimina configuraciones inválidas que generan mensajes de diagnóstico.
Pon un WAF delante, si aún no lo tienes. Cloudflare publicó reglas para los vectores conocidos, pero las considera una medida temporal.
Rota los secretos. Es el paso más olvidado y probablemente el más importante, porque la 109619 permite leer memoria de otras peticiones. Prioriza:
- contraseñas de base de datos;
- claves de API de terceros (pagos, correo, SMS, CRM);
- claves de sesión y salts (en WordPress, las constantes AUTH_KEY, SECURE_AUTH_KEY y similares en wp-config.php);
- tokens OAuth y secretos de firma JWT;
- credenciales de nube (claves de acceso de AWS, GCP, Azure).
Invalida las sesiones de usuarios y administradores después de rotar.
Revisa los logs desde ~17/10: picos de errores 500, mensajes de out of memory, subidas multipart inusuales y reinicios anómalos de workers.
Busca indicios de compromiso: archivos PHP nuevos en directorios de subida, web shells, administradores creados recientemente, tareas programadas desconocidas.

Notas para WordPress

WordPress es el caso más habitual y fue uno de los objetivos demostrados. Tres puntos concretos:

Hosting gestionado: pregunta a tu proveedor, por escrito, qué versión y qué build de PHP usas y cuándo se aplicó el parche. Guarda la respuesta como evidencia.
Salts: generar valores nuevos en wp-config.php cierra todas las sesiones, que es justo lo que quieres tras la rotación.
Los plugins no son la causa, pero amplían el daño. Un atacante con ejecución de código lee wp-config.php, así que trata la contraseña de la base de datos como expuesta si el servidor fue vulnerable.

Cómo priorizar una flota

Si gestionas decenas de servidores no puedes hacerlo todo a la vez. Un orden razonable:

Servidores expuestos a internet con mod_php.
Sistemas que tratan datos de pago, salud o credenciales (paneles, APIs de login, checkout).
Hosts con PHP 8.1 o anterior, que necesitan backport o migración.
Entornos internos y de preproducción, que a menudo comparten secretos con producción.

Para cada host, registra: versión antes y después, fecha del parche, mitigación aplicada y secretos rotados. Ese registro es lo que pedirán auditores, clientes enterprise y aseguradoras.

Cómo puede ayudar Pentest Machine

Actualizamos nuestra propia infraestructura a PHP 8.4.27 y aplicamos la mitigación de session.upload_progress justo después de la divulgación. A partir de esa experiencia montamos una respuesta PHP2Shell de alcance cerrado:

inventario de versión y SAPI (mod_php, FPM, CGI) de cada servidor en alcance;
revisión de logs en busca de señales de explotación;
plan priorizado de rotación de secretos;
informe ejecutivo con evidencias para auditoría y clientes;
retest tras las correcciones.

Entregamos en un máximo de 72 horas desde que se concede el acceso. Recibes una propuesta con precio cerrado en 24 horas: pide un presupuesto.

¿Solo quieres una primera visión? Nuestra Radiografía de Seguridad Externa es gratuita y pasiva, y ahora señala indicios de PHP expuesto. No envía carga de ataque ni puede confirmar si el parche está aplicado: sirve para saber por dónde empezar.

Preguntas frecuentes

¿Qué es PHP2Shell?

Es el nombre de dos vulnerabilidades críticas en el núcleo de PHP, CVE-2026-109618 y CVE-2026-109619, divulgadas el 21/10/2026. Permiten ejecución remota de código sin autenticación y fuga de memoria del proceso.

¿Qué versiones de PHP lo corrigen?

PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y anteriores no reciben release oficial; se publicaron backports mínimos de código fuente para 7.4, 8.0 y 8.1, y algunas distribuciones ofrecen paquetes corregidos.

¿Basta con actualizar PHP?

No. El parche impide nuevos ataques, pero la CVE-2026-109619 permite leer memoria de otras peticiones. Si el servidor estuvo expuesto, rota contraseñas, claves de API, salts y tokens, e invalida las sesiones.

Mi sitio está detrás de Cloudflare. ¿Estoy protegido?

En parte. Cloudflare publicó reglas de WAF para los vectores conocidos, pero las trata como temporales. Actualizar PHP sigue siendo obligatorio.

¿Cómo sé si mi WordPress se vio afectado?

Confirma la versión de PHP con tu proveedor o en el servidor, revisa los logs desde el 17/10 en busca de errores 500 y out of memory, busca archivos PHP nuevos en wp-content/uploads y administradores creados recientemente. Ante la duda, rota los secretos.

¿Un escáner externo puede decirme si soy vulnerable?

No con certeza. La versión suele estar oculta y las distribuciones corrigen sin cambiar el número. Un escáner pasivo como la Radiografía señala indicios de exposición; la confirmación exige acceso al servidor.