El parche para PHP2Shell ya está disponible, pero la mayoría de los sitios que lo necesitan no tienen ningún botón que puedan presionar. Las fallas están en el propio PHP, el motor que hace funcionar todas las páginas de WordPress, Joomla y Drupal, por debajo del CMS, sus plugins y su pantalla de inicio de sesión. Actualizar WordPress no sirve para corregirlas. El intérprete parcheado tiene que llegar desde quien administra el servidor: la empresa de hosting, el paquete de la distribución de Linux o la imagen del contenedor. Hasta que eso ocurra, el sitio tendrá que esperar, sin importar lo que haga su propietario.

Ese es el aspecto de la historia que suelen omitir los titulares de «instala el parche ahora». El equipo de PHP ya hizo su parte. Que su trabajo llegue a un servidor concreto depende de una cadena de distribución que avanza al ritmo de su eslabón más lento, y el primer día dejó en evidencia la distancia entre unos y otros. Si el propietario no sabe de dónde proviene su PHP, no puede determinar qué tan expuesto sigue estando.

Por qué actualizar WordPress no soluciona el problema

Como los errores están en el intérprete, el aviso de seguridad de PHP abarca todas las instalaciones que reciben solicitudes web, desde PHP-FPM y mod_php de Apache hasta php-cgi, FrankenPHP y LiteSpeed. The Hacker News señala que incluso una página básica con un «Hello World» en una versión vulnerable puede ser atacada. El peor escenario se da con mod_php: una sola solicitud de alguien sin cuenta puede activar el ataque antes de que se ejecute cualquier código de la aplicación, de modo que ningún plugin de seguridad ni pantalla de inicio de sesión llega a detectarlo.

Wordfence, proveedor de seguridad para WordPress, les dijo a los propietarios de sitios, según informó The Verge, que el parche no puede llegar mediante las actualizaciones automáticas y que deben averiguar quién es responsable de su PHP. Laravel Forge les comunicó lo mismo a sus clientes sobre sus servidores: sus actualizaciones de seguridad automáticas no corrigen PHP, y las actualizaciones desatendidas de Ubuntu solo descargan paquetes del repositorio de Ubuntu, no de los repositorios de terceros desde los que Forge instala PHP.

Esas fuentes de paquetes no se actualizaron al mismo tiempo. El día del lanzamiento, el servicio de administración de sitios mySites.guru informó que EasyApache 4 de cPanel ya tenía compilaciones corregidas a los pocos minutos de publicarse los avisos, mientras que la PPA de Ondřej Surý —la fuente de paquetes de Ubuntu de la que depende el propio Laravel Forge— y el repositorio de Remi todavía no las tenían. InMotion Hosting dijo que sus servidores compartidos y de WordPress seguían a la espera de las compilaciones de CloudLinux. Entre los sitios activos que monitorea mySites.guru, apenas el 0,08 % reportaba una versión corregida de PHP a las 13:52 UTC.

El número de versión puede llevarte a engaño

Verificarlo no es tan sencillo como revisar un número. Ubuntu, Debian y Red Hat incorporan las correcciones de seguridad sin cambiar la versión original, por lo que un servidor Ubuntu 24.04 parcheado sigue mostrando un paquete 8.3.6. The Hacker News, citando a Debian, recomienda buscar el CVE en el registro de cambios del paquete en lugar de confiar en la cadena de versión. mySites.guru advierte sobre otra trampa: el binario de PHP que responde a php -v en la línea de comandos no suele ser el mismo que sirve las páginas, así que hay que comprobar la versión que informa el propio sitio.

Después, el parche tiene que cargarse. Tanto el aviso de PHP como Forge hacen hincapié en que hay que reiniciar Apache, PHP-FPM y todos los procesos de larga duración. Los trabajadores de las colas y otros procesos en segundo plano siguen usando el intérprete anterior hasta que se reinician, aunque los archivos del parche ya estén en el disco.

Quiénes no recibirán un parche oficial

Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que cubren CVE-2026-109618 y CVE-2026-109619, ambas con una calificación de 9,2 en CVSS v4.0. PHP 8.1 y las versiones anteriores no reciben nada del proyecto PHP, salvo parches mínimos al código fuente para las versiones 7.4, 8.0 y 8.1, dirigidos a quienes compilan PHP por su cuenta. Algunos proveedores cubren esa brecha: InMotion afirma que cPanel incorporó parches a sus paquetes de las versiones 7.4 a 8.1 y que CloudLinux está corrigiendo todas las versiones que distribuye, mientras que CentOS 7 no recibirá ninguna corrección.

Ese grupo rezagado no es pequeño. El día anterior al lanzamiento, el 22,7 % de los sitios activos de Joomla y WordPress que monitorea mySites.guru usaba PHP 8.1 o una versión anterior, y el 16,6 % seguía en PHP 7 o anterior. La empresa atribuye parte del problema al propio WordPress, que recomienda PHP 8.3, pero todavía considera compatible la versión 7.4, retirada hace mucho tiempo. PHP 8.2 sí recibió este parche, pero su soporte de seguridad termina el 31 de diciembre de 2026.

Qué bloquea la configuración provisional

La solución temporal que circuló antes del lanzamiento, establecer session.upload_progress.enabled=0, existe, pero solo ofrece protección parcial. PHP dice que bloquea las vías confirmadas a través de sesiones para CVE-2026-109619, pero no otras variantes, y que debe configurarse en php.ini o en la configuración del servidor o del grupo de procesos; después, hay que reiniciar a todos los procesos trabajadores. En PHP 8.5, fatal_error_backtraces=0 cierra otra vía confirmada. Ninguna de las dos medidas afecta a CVE-2026-109618, para el que PHP recomienda establecer un memory_limit=-1 que no se pueda sobrescribir, fijar un post_max_size bajo y limitar el tamaño de las solicitudes en el servidor web o el proxy. La propia documentación de PHP dice que no hay mitigaciones completas. InMotion señala que WordPress, Joomla, Drupal, Magento y PrestaShop no usan la función de progreso de carga, así que desactivarla no les causa ningún problema.

Cloudflare activó reglas de firewall para todos sus planes, una medida provisional, según la describió Dane Knecht, su director de tecnología. Como señala mySites.guru, solo sirven si el servidor que está detrás de Cloudflare rechaza el tráfico que intenta evitarlo y conectarse directamente a su dirección IP.

Los ataques hasta ahora

watchTowr afirma que sus honeypots registraron intentos de explotar ambas fallas el día del lanzamiento, y Cloudflare observó que los atacantes modificaban sus cargas para evadir las reglas. Ninguna fuente ha confirmado que se haya vulnerado un servidor en particular. Algunos operadores prefirieron no correr riesgos: The Hacker News informa que BambooHR dejó su servicio fuera de línea y que varios servicios públicos de los Países Bajos, incluido DigiD, también dejaron de funcionar como medida preventiva. El CERT de la UE y el National Cyber Security Centre del Reino Unido recomendaron a las organizaciones que no puedan instalar el parche aislar las aplicaciones expuestas o dejarlas fuera de línea.

Las fallas fueron descubiertas por Wiz Research, Calif y el equipo Codex Security de OpenAI. Según PHP Foundation, indicios de la falla de memoria aparecieron durante una auditoría en 2024, pero la corrección quedó estancada durante meses, una demora que calificó de «falla estructural». Los investigadores afirman que los modelos de IA ayudaron a convertir esos errores, presentes desde hacía una década, en exploits funcionales en aproximadamente una semana.

PHP necesitó una auditoría, meses de bloqueo y una filtración para publicar este parche. Para un sitio con hosting compartido, el último paso es abrir un ticket de soporte.

Etiquetas: Cloudflare, PHP, PHP2Shell, vulnerabilidades, WordPress