PHP2Shell CVE-2026-109618 y 109619: cómo protegerse

Actualizado el 22 de octubre de 2026: ya hay intentos de explotación. Si su empresa tiene sitios o aplicaciones en PHP, actualice hoy.

PHP2Shell es el nombre de dos vulnerabilidades críticas en el motor de PHP, CVE-2026-109618 y CVE-2026-109619, con puntaje CVSS 4.0 de 9.2, publicadas el 21 de octubre de 2026. Un atacante remoto y sin credenciales puede aprovecharlas para ejecutar código en el servidor. La solución es actualizar a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35 y reiniciar todos los procesos de PHP.

Anatomía del ataque descrito en el artículo.

¿Qué es PHP2Shell?

Son dos fallas en la forma en que PHP maneja cada petición web, antes de que corra el código de su aplicación:

CVE-2026-109618 (agotamiento de memoria): si la memoria se acaba mientras PHP prepara los datos internos de la petición, la limpieza posterior trata como válidos datos que quedaron a medio crear.
CVE-2026-109619 (uso de memoria liberada): información de una petición queda apuntando a memoria ya liberada y la siguiente petición que atiende el mismo proceso puede usarla. PHP confirma que permite leer memoria del servidor.

Afecta a PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El escenario más riesgoso es mod_php: una sola petición sin autenticación puede disparar el ataque antes de que su aplicación haga nada. Por eso no importa si su WordPress, Laravel o Moodle está al día: la falla está en PHP.

¿Qué versiones de PHP están afectadas por CVE-2026-109618 y CVE-2026-109619?

PHP 8.5 anterior a 8.5.12 → actualice a 8.5.12.

PHP 8.4 anterior a 8.4.27 → actualice a 8.4.27.

PHP 8.3 anterior a 8.3.36 → actualice a 8.3.36.

PHP 8.2 anterior a 8.2.35 → actualice a 8.2.35.

PHP 7.4 a 8.1: no hay versión oficial; use el paquete corregido de su distribución o proveedor LTS, o los parches mínimos del equipo de seguridad de PHP.

PHP 5.4 a 7.3: fuera de soporte y sin corrección: hay que migrar a una versión soportada.

¿Se está explotando PHP2Shell?

Sí, hay intentos. Amazon detectó un intento contra sus señuelos (honeypots) el 17 de octubre, cuatro días antes de la publicación, y hoy reporta explotación amplia. Los identificadores se filtraron el 20 de octubre y PHP adelantó un día su actualización, que salió el 21 de octubre a las 14:00 UTC. Unit 42 (Palo Alto Networks) cuenta más de 22,6 millones de instancias expuestas que podrían ser vulnerables.

Dos aclaraciones: el puntaje oficial es 9.2, no el 10.0 que circuló al principio, y la PHP Foundation no había identificado exploits funcionales al publicar; los códigos de prueba que circulan no están verificados. Aun así, la recomendación de todos los fabricantes es la misma: parchear ya.

¿Qué debe hacer hoy su empresa?

1. Inventario: identifique dónde corre PHP: servidores, contenedores, hosting compartido o paneles como Plesk y cPanel, y equipos que lo traen por dentro.

2. Actualización: instale la versión corregida de su rama y reinicie todos los procesos de PHP (PHP-FPM, Apache); sin reinicio el parche no aplica.

3. Si no puede actualizar hoy: PHP sugiere session.upload_progress.enabled=0 (CVE-2026-109619; en PHP 8.5 también fatal_error_backtraces=0) y memory_limit=-1 sin que la aplicación pueda cambiarlo (CVE-2026-109618), con un límite de memoria del contenedor para no quedarse sin servicio. Reinicie los procesos después. Son mitigaciones, no la solución.

4. Parche virtual en el WAF mientras actualiza (vea abajo).

5. Revisión de registros desde el 17 de octubre: errores de memoria de PHP, procesos que se reinician y peticiones POST anómalas.

6. Aislamiento: si una aplicación expuesta a internet no se puede parchear, sáquela de internet hasta corregirla.

¿Cómo protege Rescue WAF mientras actualiza PHP?

Un firewall de aplicaciones web no corrige PHP, pero reduce la exposición mientras se aplican los parches. En Rescue WAF se configuran por sitio, como parche virtual:

Bloqueo del vector de CVE-2026-109619: peticiones POST que combinan la cookie de sesión de PHP (PHPSESSID) con el campo PHP_SESSION_UPLOAD_PROGRESS; primero en modo observación para no afectar la aplicación.

Límite de tamaño del cuerpo en las rutas que no reciben archivos, que reduce el agotamiento de memoria de CVE-2026-109618.

Bloqueo de multipart/form-data donde la aplicación no recibe archivos.

Límite de peticiones POST por IP y bloqueo por reputación con CrowdSec para cortar a quienes ya están escaneando.

Registro de cada intento, que llega al SOC como incidente.

Los límites son claros: según AWS, una de las dos fallas queda «en gran parte fuera del alcance de cualquier firewall de aplicaciones web», y el tráfico que no pasa por el WAF no queda protegido. El parche sigue siendo obligatorio.

¿Qué aporta Rescue SOC frente a PHP2Shell?

Inventario de vulnerabilidades: los agentes reportan el software de cada servidor, así se ubican los que tienen una versión de PHP afectada y se priorizan los expuestos a internet.

Detección después de un ataque: alertas cuando el proceso de PHP lanza comandos, aparecen archivos nuevos en las carpetas del sitio (posibles web shells) o hay conexiones salientes inusuales.

Correlación con Rescue WAF: un intento bloqueado en el WAF y actividad extraña en el mismo servidor se convierten en un caso prioritario.

Respuesta con analistas: se valida la alerta, se contiene el equipo y se documenta cada acción.

Conozca Rescue SOC. Si sospecha que su servidor ya fue comprometido, active nuestra respuesta ante incidentes 24/7; y después de parchear, un pentest confirma que la corrección quedó bien aplicada.

Preguntas frecuentes sobre PHP2Shell

¿Qué es PHP2Shell?

Es el nombre de dos vulnerabilidades críticas en el motor de PHP, CVE-2026-109618 y CVE-2026-109619, publicadas el 21 de octubre de 2026. Permiten a un atacante remoto sin credenciales ejecutar código o leer memoria del servidor.

¿Mi WordPress es vulnerable a CVE-2026-109618?

Si el servidor usa una versión de PHP afectada, sí, aunque WordPress y sus plugins estén al día: la falla está en PHP, no en la aplicación. Pida a su proveedor de hosting que confirme la versión de PHP y la actualice.

¿Cómo sé qué versión de PHP tengo?

En el servidor, con el comando php -v; en hosting compartido, en el panel (Plesk, cPanel) o preguntando al proveedor. No deje expuesta una página phpinfo().

¿Cuál es el puntaje CVSS de CVE-2026-109618 y CVE-2026-109619?

9.2 en CVSS 4.0 para ambas. El 10.0 que circuló al principio no es el puntaje oficial de PHP.

¿Basta con un WAF para protegerse de PHP2Shell?

No. Un WAF reduce la exposición mientras se actualiza, pero no corrige PHP y una de las fallas queda en gran parte fuera de su alcance. Hay que instalar la versión corregida.

¿Qué hago si uso PHP 7.4, 8.0 u 8.1?

No hay versión oficial corregida: use el paquete corregido de su distribución o de un proveedor LTS, o los parches mínimos de PHP, y planee la migración a una versión soportada.