PHP2Shell: la falla que obliga a revisar cada servidor PHP

Esta semana el ecosistema web vivió uno de los episodios de seguridad más serios de los últimos años. El martes 20 de octubre se filtraron, antes de lo previsto, los detalles de dos vulnerabilidades críticas en el propio motor de PHP. Un día después, el equipo de PHP adelantó la publicación de los parches; para cuando estos llegaron, ya circulaba tráfico malicioso intentando explotarlas.

Escribo estas líneas porque, en incidentes como este, la mayoría de las preguntas tiene la misma raíz: ¿me afecta si uso WordPress?, ¿basta con actualizar Laravel?, ¿mi hosting ya lo resolvió? La respuesta corta es que sí afecta, que actualizar la aplicación no basta y que conviene verificarlo en lugar de suponerlo.

En resumen

• Dos fallas críticas en PHP: CVE-2026-109618 y CVE-2026-109619, ambas con puntaje 9.2 en CVSS v4.0, permiten ejecutar código en el servidor sin autenticación.
• Afectan a prácticamente todo PHP que atiende peticiones web, desde la versión 5.4 (2012) en adelante.
• Versiones corregidas: 8.5.12, 8.4.27, 8.3.36 y 8.2.35, publicadas el 21 de octubre a las 14:00 UTC (09:00 hora de Lima).
• Ya hay intentos de explotación documentados. Aún no existe un conteo confiable de sitios comprometidos.

1. Cómo se desarrolló el incidente

Las fallas no se descubrieron esta semana. Fueron reportadas en agosto al equipo de PHP mediante un proceso de divulgación coordinada, que debía culminar el jueves 22 de octubre. La filtración rompió ese calendario y obligó a acelerar todo un día.

2. Qué son las dos vulnerabilidades

El conjunto recibió el apodo de PHP2Shell, tomado del nombre de la herramienta de explotación que apareció en la filtración. Wiz señala que ambas CVE agrupan en realidad cuatro problemas de seguridad de memoria en PHP.

CVE-2026-109618: corrupción por falta de memoria

Si PHP se queda sin memoria en medio de una operación, los datos internos de la petición quedan a medio inicializar y la rutina de limpieza los trata después como válidos. Eso abre el camino a la ejecución de código. Además, según Sansec, esta falla puede devolver al atacante fragmentos de memoria ya liberada del proceso dentro de la cookie PHPSESSID: memoria que puede contener contraseñas, tokens de sesión, claves de API e incluso claves privadas TLS de otras peticiones. Es una fuga de información comparable a lo que fue Heartbleed.

CVE-2026-109619: estado global obsoleto

Cierto estado interno ligado a una petición sobrevive después de que su memoria fue liberada. Una petición posterior atendida por el mismo worker puede utilizar ese estado antes de que se reinicialice, lo que también permite ejecutar código.

Por qué son tan graves

• No requieren usuario ni contraseña: basta con enviar peticiones HTTP manipuladas.
• El código del atacante corre con los permisos del usuario del worker de PHP, que suele tener acceso a los archivos del sitio, a su configuración y a las credenciales de la base de datos.
• Están afectadas todas las formas de servir PHP: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El caso más riesgoso es mod_php, porque el ataque se produce antes de que se ejecute el código de la aplicación.
• Una ruta de ataque confirmada es session.upload_progress, activada por defecto, que se dispara con cualquier petición POST antes de que la aplicación intervenga. No es la única ruta.

3. Por qué ninguna aplicación puede defenderse sola

Es útil pensar en tres capas. La primera es la aplicación (WordPress, Laravel, Drupal, plugins): actualizarla no corrige PHP2Shell. La segunda es el runtime de PHP, donde están ambas fallas y donde se aplica el parche. La tercera es el origen de los binarios (el proveedor de hosting, el repositorio de la distribución, la imagen Docker o el panel de control), que determina cuándo llega realmente la versión corregida.

Esta distinción importa porque la falla ocurre cuando PHP procesa la petición, antes de que la aplicación decida nada. Por eso, ni el código más limpio ni un firewall de aplicación instalado como plugin pueden detenerla por sí solos. Wiz llegó a demostrar que incluso una aplicación mínima tipo «Hola mundo» es explotable sobre una versión vulnerable de PHP.

4. WordPress y WooCommerce

WordPress es, por volumen, la plataforma con más sitios expuestos. Wiz demostró ejecución remota de código sin autenticación sobre las imágenes de contenedor actuales de WordPress, y Calif lo confirmó sobre WordPress 7.1.2. Los puntos clave para quien administra sitios WordPress son estos:

• Actualizar WordPress, el tema o los plugins no corrige el problema. La falla está en PHP.
• El modo mantenimiento no protege, porque PHP procesa cada petición antes de que WordPress revise si el sitio está en mantenimiento.
• Las tiendas WooCommerce están expuestas aunque su propio código esté limpio.
• En hosting compartido no es posible actualizar PHP por cuenta propia. Hay que confirmar con el proveedor que la versión que sirve el sitio ya está corregida. Si el sitio corre en PHP 8.1 o anterior, conviene cambiarlo a 8.2 o superior desde el panel (en cPanel, desde MultiPHP Manager), previa prueba de compatibilidad.
• No hay que confundirlo con WP2Shell, la cadena de fallas del núcleo de WordPress de julio de 2026. Aquella sí se corregía actualizando WordPress; esta no.

5. Laravel y Symfony

En los frameworks el malentendido más común es suponer que un composer update resuelve el problema. No lo hace: Laravel es código PHP, y la corrección está en el binario de PHP que lo ejecuta. Calif confirmó la explotación sobre Laravel 13.11 y Symfony 8.1. Según la plataforma de despliegue, la situación es distinta:

6. Otras plataformas basadas en PHP

La lista de aplicaciones en las que los investigadores confirmaron ejecución remota de código sin autenticación da una idea del alcance. No se trata solo de sitios web públicos: también hay herramientas internas que muchas organizaciones exponen a internet sin pensarlo dos veces.

Paneles de hosting y repositorios

• cPanel/WHM: la actualización llega por EasyApache 4. Conviene verificar cada versión instalada y no solo la versión por defecto del servidor.
• Plesk: su aviso oficial lista como corregidas para Linux las mismas versiones (8.5.12, 8.4.27, 8.3.36 y 8.2.35). Al momento de su publicación, PHP 8.0 y 8.1, las compilaciones para Windows y el PHP interno del propio panel figuraban aún en desarrollo. Para PHP 5.6, 7.2 y 7.3 remite al soporte extendido de pago de TuxCare.
• Repositorio de Remi (habitual en RHEL, AlmaLinux y Rocky): según Sansec, la corrección no estuvo disponible allí el 21 de octubre.
• Distribuciones: Ubuntu publicó su aviso USN-8948-1. En Debian, Ubuntu y derivados conviene revisar el registro de cambios del paquete, porque el número de versión puede no reflejar un parche retroportado.

7. ¿Quién ha sido atacado hasta ahora?

Aquí conviene ser preciso, porque hay tres cifras distintas que suelen mezclarse: los sistemas expuestos, los intentos de ataque y los compromisos confirmados. La primera es enorme; la segunda está creciendo; la tercera, al cierre de este artículo, todavía no tiene un recuento público confiable. Esto es lo que han reportado las fuentes que observan tráfico real:

En contraste, la CISA indicó que al publicar su alerta no había observado explotación, y ninguna de las dos CVE figuraba aún en su catálogo de vulnerabilidades explotadas (KEV). La lectura prudente es la que hacen la mayoría de los analistas: con pruebas de concepto públicas y detalles técnicos ya divulgados, hay que tratar a todo servidor sin parchar como objetivo activo. Sansec, por ejemplo, anticipó ataques masivos a partir de la publicación del parche.

8. Qué recomiendo hacer hoy

1. Inventariar todo PHP. No solo el servidor web principal: también PHP-FPM, mod_php, la línea de comandos, contenedores, paneles, equipos de terceros y entornos de prueba publicados. En cPanel, revisar MultiPHP Manager; en Plesk, Herramientas y configuración › Configuración de PHP y la configuración de hosting de cada suscripción, porque cada sitio puede usar una versión distinta.
2. Actualizar y verificar la versión real. Instalar 8.5.12, 8.4.27, 8.3.36 u 8.2.35 y comprobar con php -v, phpinfo() y el registro de cambios del paquete. Un apt upgrade exitoso no garantiza que el repositorio ya tuviera la versión corregida. Después, reiniciar PHP-FPM o Apache para que los procesos carguen el binario nuevo.
3. Atender las versiones sin soporte. PHP 8.1 y anteriores no reciben versión oficial. Por la gravedad del caso, el equipo de PHP publicó correcciones mínimas en código fuente para 7.4, 8.0 y 8.1, pero la salida sostenible es migrar. Si no es posible actualizar de inmediato, la CISA y el NCSC del Reino Unido recomiendan desconectar el sistema hasta corregirlo.
4. Usar contención solo como paliativo. Un WAF con reglas para PHP2Shell (Cloudflare las ofrece incluso en su plan gratuito) reduce el riesgo, y desactivar session.upload_progress cierra una de las rutas conocidas. Ninguna de las dos medidas sustituye el parche: hay otras rutas de ataque y los atacantes ya están modificando sus cargas para evadir filtros.
5. Buscar indicios de compromiso. Revisar los registros desde el 20 de octubre en busca de peticiones POST que terminen en error 500, errores fatales por agotamiento de memoria, caídas repetidas de workers, procesos de shell lanzados por el usuario de PHP y archivos .php nuevos o modificados en directorios de carga.
6. Rotar secretos. Por la fuga de memoria de CVE-2026-109618, en servidores que estuvieron expuestos sin parche conviene rotar contraseñas de base de datos, claves de API y tokens, invalidar sesiones activas y evaluar la renovación de certificados TLS.
7. Planificar lo que viene. PHP 8.2 deja de recibir correcciones de seguridad el 31 de diciembre de 2026. Quien hoy parcha sobre 8.2 debería tener ya programada su migración.

9. Lo que nos deja este episodio

PHP2Shell es un recordatorio de que la seguridad de una aplicación descansa sobre capas que el equipo de desarrollo rara vez controla directamente. Un sitio puede tener el código impecable, los plugins al día y aun así quedar expuesto por el motor sobre el que corre.

Las organizaciones que mejor están respondiendo a este incidente tienen tres cosas en común: saben con exactitud qué versiones de PHP ejecutan y dónde; tienen un procedimiento para aplicar parches de infraestructura en horas y no en semanas; y cuentan con una capa de protección perimetral que les da margen mientras parchan. Ninguna de las tres se improvisa durante una emergencia.

Si su organización depende de WordPress, Laravel o cualquier otra plataforma PHP, la pregunta para hoy no es si está afectada, sino si ya lo verificó. Y la pregunta para mañana es cuánto tiempo le tomaría responder la próxima vez.

Fuentes consultadas

• CISA — Critical Vulnerabilities in PHP Require Immediate Patching (21/10/2026)
• CERT-EU — Security Advisory 2026-018: Critical Vulnerabilities in PHP
• Sansec — PHP2Shell: Critical PHP RCE
• Cloudflare — Cloudflare deploys protections against php2shell vulnerability
• Google Cloud — Responding to core PHP vulnerabilities
• SecurityWeek — PHP2Shell Patches Land as First Exploitation Attempts Hit Sensors
• Help Net Security — PHP2Shell: Critical PHP vulnerabilities patched
• The Hacker News — PHP2Shell: Two Unpatched Critical PHP RCE Flaws
• Tenable — php2shell FAQ
• watchTowr — PHP2Shell FAQ
• Securing Laravel — Laravel Security Notice: Critical PHP Security Release
• BrillMark — PHP2Shell: Is Your WordPress, Laravel or PHP Site Affected?
• Appycodes — PHP2Shell: affected versions and how to update PHP
• Jason Burns — PHP2Shell: how to patch it on your host
• Equixly — What we know about PHP2Shell and how to prepare
• Brandefense — PHP2Shell: PHP RCE CVE-2026-109618, 109619
• Cybaverse — PHP2Shell: Check Exposure and Hunt for Compromise

Imagen de portada: Pixabay en Pexels.