PHP2Shell: las dos vulnerabilidades críticas de PHP (CVE-2026-109618 y CVE-2026-109619)

El 21 de octubre de 2026, el equipo de seguridad de PHP publicó parches de emergencia para dos vulnerabilidades críticas del propio intérprete que permiten ejecución remota de código (RCE) sin autenticación. El problema no está en WordPress, Laravel ni en ningún plugin: está en PHP, por debajo de la aplicación. Por eso un sitio con todo el código al día sigue expuesto si el PHP que corre abajo no está parcheado.

Las fallas, bautizadas PHP2Shell, son CVE-2026-109618 y CVE-2026-109619. Ambas tienen una puntuación CVSS v4.0 de 9,2.

En resumen

Qué permiten: ejecutar código en el servidor web sin credenciales y, en un caso, leer memoria de otros pedidos (contraseñas, tokens, claves).
Qué versiones están afectadas: todas las ramas desde PHP 5.4 hasta 8.5.11, según Google Cloud.
Dónde está el arreglo: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Para 8.1 y anteriores no hay releases oficiales: solo backports de código fuente o los de tu distribución.
Estado de explotación: Cloudflare reportó ataques tempranos antes de la publicación del parche, y ya circulan write-ups y una herramienta de explotación públicos.
Qué hacer hoy: actualizar PHP en cada servidor y contenedor. Las mitigaciones temporales reducen superficie, pero PHP aclara que no hay mitigación completa.

Cómo funcionan las dos vulnerabilidades

Ambas nacen del mismo patrón: cuando una petición termina de forma abrupta (típicamente por quedarse sin memoria), PHP puede dejar su estado interno a medio inicializar o apuntando a memoria ya liberada. Una petición posterior, atendida por el mismo proceso, usa ese estado corrupto y el atacante lo convierte en corrupción de memoria controlada. Así lo describe el aviso oficial de PHP y lo detalla la investigación de Wiz.

CVE	Descripción oficial	Fallas concretas que demostraron los investigadores	Impacto demostrado
CVE-2026-109618	RCE por corrupción tras falta de memoria (OOM): la limpieza trata datos a medio inicializar como válidos	Use-after-free en el seguimiento de progreso de subidas de la extensión de sesión; filtración remota de memoria del proceso	RCE sin autenticación en WordPress, Drupal y Joomla; lectura de memoria sin RCE
CVE-2026-109619	RCE por estado global residual: estado de una petición sobrevive a su memoria liberada y lo usa la siguiente	Use-after-free del backtrace del último error fatal; confusión de tipos en OPcache	RCE sin autenticación en Drupal y WordPress

Wiz aclara que además existen variantes no listadas que caen bajo los mismos dos CVE, y que el parche de PHP corrige la causa de fondo para todas. Los nombres de bugs de la tabla vienen de Wiz; el aviso oficial usa las descripciones de la segunda columna.

Dos detalles que explican la gravedad

Se ejecuta antes de tu código. PHP procesa los cuerpos multipart/form-data (el formato de las subidas de archivos) al iniciar la petición, antes de cargar la aplicación. PHP considera el riesgo más alto con Apache y mod_php, con un exploit demostrado en que una petición anónima dispara el ataque antes de que corra código de la aplicación. PHP-FPM, php-cgi, FrankenPHP y LiteSpeed también están afectados.
Sirve hasta un “Hello World”. Según Wiz, la explotación no depende de fallas en la aplicación. Además, la lectura de memoria funciona aunque la aplicación nunca llame a session_start(), y puede exponer datos de otras peticiones, como contraseñas, tokens de sesión, claves de API y certificados.

Calif, que encontró los bugs junto con OpenAI y Wiz, confirmó RCE sin autenticación en WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony y WHMCS. Su recorrido histórico es llamativo: el primer riesgo de este tipo con el límite de memoria de PHP se había descrito en 2004, un bug relacionado se reportó en 2020 y una auditoría lo reencontró en 2024 sin probar explotación.

Cronología: de agosto al parche de emergencia

La divulgación coordinada se rompió a último momento: los detalles se filtraron el 20 de octubre, antes del lanzamiento previsto. Horarios en UTC.

Fecha	Hecho
21 oct, ~14:00	PHP publica 8.5.12, 8.4.27, 8.3.36 y 8.2.35 y se divulgan las fallas (PHP); CERT-EU registra la publicación a las 13:30
21 oct, 07:43	Cloudflare reporta ataques tempranos, antes del parche (Sansec)
20 oct	PHP anuncia un lanzamiento crítico para el 21 a las 14:00 y reserva el derecho de adelantarlo; se filtran detalles y watchTowr confirma RCE
24 ago	Wiz Research reporta las vulnerabilidades a PHP; PHP las reconoce el 21 de septiembre (Wiz)
11 ago	Calif reporta el primer bug y abre la divulgación coordinada (Calif)
1 ago	Calif encuentra varias rutas de RCE

Según el aviso de PHP, la ola de cambios también incluyó backports de código fuente para PHP 7.4, 8.0 y 8.1, que ya no tienen soporte oficial.

A quién afecta y qué tan grande es la exposición

A cualquier instalación de PHP que atienda pedidos web, sin importar el servidor: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed. Wiz estima que PHP está detrás del 70 % de los sitios web del mundo; BleepingComputer cita un rango de 75 % a 80 %. También alcanza a productos que traen PHP embebido: Cisco y Plesk publicaron avisos propios.

El análisis de VirusTotal del 21 de octubre dimensiona la superficie expuesta en internet. Son hosts con PHP detectado, no hosts confirmados como vulnerables:

Segmento	IPs (aprox.)
Con PHP detectado	5,1 millones
Con al menos un puerto abierto	3,8 millones
Que muestran su versión de PHP	1,1 millones
Rama soportada (8.2 a 8.5)	272.000
Rama fuera de soporte (5.4 a 8.1)	758.000

Tres lecturas útiles de esos números:

Cuatro de cada cinco servidores PHP ocultan su versión, así que buscar solo por cabecera subestima el problema. Ocultar la versión no corrige la falla.
Alrededor de dos de cada tres servidores que sí muestran versión corren una rama sin parches de seguridad oficiales.
Estar al día no alcanzaba: unas 85.000 IPs corrían las versiones de septiembre (8.3.35, 8.2.34, 8.4.26 y 8.5.11), las últimas antes de este arreglo.

Hay además dos complicaciones de infraestructura. PHP pidió no depender del repositorio Remi (rpms.remirepo.net), muy usado en servidores RHEL, porque ese día no iba a publicar actualizaciones. Y PHP 8.2 llega a fin de vida el 31 de diciembre de 2026, así que conviene planificar la migración ahora.

Qué hacer ahora

La única solución completa es actualizar PHP. Este es el orden que recomiendan PHP, el NCSC del Reino Unido y CISA.

Inventariar todo el PHP de la organización. Incluir servidores, contenedores, imágenes base y productos que traigan PHP embebido. El NCSC pide no limitar la búsqueda a versiones viejas, porque todas pueden estar afectadas.
Actualizar a una versión corregida.
- PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, desde php.net o desde los paquetes de la distribución.
- PHP 8.1 y anteriores no reciben releases oficiales: pedir el backport a la distribución o al proveedor LTS, o migrar a una rama soportada. Para quienes compilan desde fuente, PHP publicó backports mínimos para 7.4, 8.0 y 8.1.
- Quienes usan el repositorio Remi deben cambiar a paquetes de su distribución o compilar desde fuente.
Si no se puede actualizar hoy, aplicar mitigaciones parciales. Reducen rutas de ataque, pero PHP aclara que no vuelven seguro un servidor.
- CVE-2026-109618: memory_limit=-1 fijado donde la aplicación no pueda cambiarlo (por ejemplo php_admin_value en el pool de FPM), y post_max_size bajo (8M sin subidas, 32M con subidas) con upload_max_filesize menor. Con memory_limit=-1 un pedido puede consumir toda la memoria del servidor, así que hay que vigilar el consumo.
- CVE-2026-109619: session.upload_progress.enabled=0 en php.ini, el pool de FPM o la configuración del servidor, y reiniciar todos los workers. No sirve ini_set() ni .user.ini. En PHP 8.5, agregar fatal_error_backtraces=0.
- En el borde: Cloudflare publicó reglas de WAF para cargas conocidas, y Sansec propone bloquear temporalmente multipart/form-data, lo que rompe las subidas de archivos. Ambas son soluciones transitorias.
Si ni eso es posible, sacar el sistema de línea. El NCSC lo recomienda hasta poder mitigarlo.
Buscar señales de compromiso y rotar secretos. Como una de las fallas permite leer memoria de otros pedidos, tras parchear conviene revisar si hubo explotación y rotar credenciales, claves de API y sesiones de los sistemas que estuvieron expuestos. Esto último es una recomendación práctica nuestra, no una instrucción del aviso oficial.

Cómo detectar actividad sospechosa

Las fallas se ejecutan por debajo de la aplicación, así que los logs de la aplicación pueden aportar poco contexto. Wiz sugiere mirar:

Pedidos multipart/form-data inusuales seguidos de errores de límite de memoria o de respuestas HTTP 500 repetidas.
Cookies PHPSESSID en las respuestas que sean inusualmente grandes o estén malformadas, señal asociada a la filtración de memoria.
Reinicios inexplicados de workers de PHP.

Estas señales sirven para orientar una investigación, no para descartar una intrusión. Si hay sospecha, el NCSC recomienda buscar backdoors instalados por un atacante y recurrir a un proveedor de respuesta a incidentes si no se tiene la capacidad internamente.

Lo que deja PHP2Shell

1. La IA cambia la economía de la explotación. Wiz sostiene que modelos de IA de frontera hicieron viable convertir en exploits funcionales fallas que llevaban más de una década en el código, porque encadenar bugs y adaptarse a cada disposición de memoria exigía mucho trabajo manual. Calif aporta un matiz: dice que no usó modelos ni herramientas fuera del alcance de cualquiera, y que lo decisivo fue conocer el historial de vulnerabilidades del objetivo para orientar la búsqueda. Ambas lecturas coinciden en algo: el tiempo entre divulgación y explotación se acorta.

2. Las versiones sin soporte son deuda de seguridad. Más de la mitad de los servidores PHP que muestran versión corren ramas sin parches oficiales. Cuando aparece una falla crítica, esas instalaciones dependen de backports de terceros o de una migración urgente.

3. No se puede parchear lo que no se ve. PHP aparece dentro de imágenes de contenedor, paneles de hosting y appliances. El NCSC de los Países Bajos publicó un inventario de productos con dependencia de PHP que pueden estar afectados. Mantener un inventario actualizado de componentes y runtimes (por ejemplo, mediante un SBOM) es lo que separa responder en horas de responder en semanas.

4. El WAF compra tiempo, no resuelve. Cloudflare y otros proveedores desplegaron reglas de mitigación, pero Cloudflare aclaró que son temporales y que solo actualizar PHP protege por completo. Si el origen es accesible directamente, además, el WAF se puede esquivar.

Fuentes

Consultadas el 22 de octubre de 2026. Los datos pueden cambiar a medida que se publiquen nuevos parches y análisis.