La solución para PHP2Shell ya está disponible, pero la mayoría de los sitios que la necesitan no tienen ningún botón que pulsar. Los fallos están en el propio PHP, el motor que ejecuta 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 de nada. El intérprete corregido tiene que llegar de quien gestione el servidor: la empresa de alojamiento, el paquete de la distribución de Linux o la imagen del contenedor. Hasta que eso ocurra, el sitio tendrá que esperar, haga lo que haga su propietario.

Ese es el aspecto de la historia que se les escapa a los titulares de «aplica ya el parche». El equipo de PHP ha cumplido con su cometido. 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ó claro hasta qué punto están desconectados esos eslabones. Si el propietario no sabe de dónde procede su PHP, no puede determinar hasta qué punto sigue expuesto.

Por qué actualizar WordPress no lo soluciona

Como los errores están en el intérprete, el aviso de seguridad de PHP afecta a todas las instalaciones que atienden 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 vulnerable con un simple «Hello World» puede ser objeto de un ataque. El peor caso es mod_php, donde una sola solicitud de alguien sin cuenta puede desencadenarlo antes de que se ejecute cualquier código de la aplicación, por lo que ningún plugin de seguridad ni pantalla de inicio de sesión llega a detectarlo.

Wordfence, proveedor de seguridad para WordPress, advirtió a los propietarios de sitios, según informó The Verge, de que la solución no llegará mediante actualizaciones automáticas y de que deben averiguar quién es responsable de su PHP. Laravel Forge trasladó el mismo mensaje a sus propios 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 gestión de sitios mySites.guru informó de 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 la propia Laravel Forge, y el repositorio de Remi aún no las tenían. InMotion Hosting dijo que sus servidores compartidos y de WordPress estaban a la espera de las compilaciones de CloudLinux. Entre los sitios activos que supervisa mySites.guru, un 0,08 % indicaba que ejecutaba una versión corregida de PHP a las 13:52 UTC.

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

Comprobarlo no es tan sencillo como leer un número. Ubuntu, Debian y Red Hat incorporan las correcciones de seguridad sin cambiar la versión original, así que un servidor con Ubuntu 24.04 y el parche aplicado sigue mostrando el paquete 8.3.6. The Hacker News, citando a Debian, recomienda buscar el CVE en el registro de cambios del paquete en lugar de fiarse del número de versión. mySites.guru señala otra trampa: el binario de PHP que responde a php -v en la línea de comandos no suele ser el que sirve las páginas, así que hay que comprobar la versión que indica el propio sitio.

Después, el parche tiene que cargarse. Tanto el aviso de PHP como Forge insisten 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 ejecutando el intérprete antiguo hasta que se reinician, aunque los archivos del parche ya estén en el disco.

Quiénes se quedan sin una solución oficial

Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que resuelven CVE-2026-109618 y CVE-2026-109619, ambas con una puntuación de 9,2 en CVSS v4.0. PHP 8.1 y las versiones anteriores no reciben nada del proyecto PHP, más allá de correcciones mínimas incorporadas al código fuente de las versiones 7.4, 8.0 y 8.1, pensadas para quienes compilan PHP por su cuenta. Algunos proveedores cubren ese vacío: InMotion afirma que cPanel ha incorporado las correcciones a sus paquetes de la 7.4 a la 8.1 y que CloudLinux está aplicando parches a todas las versiones que distribuye, mientras que CentOS 7 no recibirá ninguna solución.

Ese grupo de versiones antiguas no es pequeño. El día anterior al lanzamiento, el 22,7 % de los sitios activos de Joomla y WordPress que supervisa mySites.guru utilizaba 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 aún considera compatible la versión 7.4, retirada hace tiempo. PHP 8.2 sí ha recibido este parche, pero su soporte de seguridad termina el 31 de diciembre de 2026.

Qué bloquea la configuración provisional

La solución provisional que circuló antes del lanzamiento, establecer session.upload_progress.enabled=0, es real, pero solo parcial. PHP dice que bloquea las vías confirmadas de ataque a través de sesiones para CVE-2026-109619, pero no otras variantes, y que hay que configurarla en php.ini o en la configuración del servidor o del grupo de procesos y, después, reiniciar todos los procesos. En PHP 8.5, fatal_error_backtraces=0 cierra otra vía confirmada. Ninguna de las dos opciones afecta a CVE-2026-109618, para el que PHP sugiere establecer un memory_limit=-1 que no se pueda anular, un post_max_size bajo y límites al tamaño de las solicitudes en el servidor web o el proxy. La propia PHP reconoce que no hay mitigaciones completas. InMotion señala que WordPress, Joomla, Drupal, Magento y PrestaShop no utilizan el progreso de carga, así que desactivarlo no les causa ningún problema.

Cloudflare activó reglas de firewall para todos sus planes, una medida provisional que su director de tecnología, Dane Knecht, calificó de parche temporal. Como apunta mySites.guru, solo sirven si el servidor que hay detrás bloquea el tráfico que evita Cloudflare y se conecta directamente a su dirección IP.

Los ataques hasta ahora

watchTowr afirma que sus honeypots registraron intentos de explotar ambos fallos el día del lanzamiento, y que Cloudflare detectó cambios en las cargas útiles de los atacantes para eludir sus reglas. Ninguna fuente ha confirmado que se haya logrado acceder a un servidor concreto. Algunos operadores no quisieron correr riesgos: The Hacker News informa de que BambooHR dejó su servicio fuera de línea y de que varios servicios públicos neerlandeses, entre ellos DigiD, se desconectaron por precaución. El CERT de la UE y el National Cyber Security Centre del Reino Unido recomendaron a las organizaciones que no puedan aplicar el parche aislar las aplicaciones expuestas o dejarlas fuera de línea.

Los fallos fueron descubiertos por Wiz Research, Calif y el equipo Codex Security de OpenAI. Según la PHP Foundation, ya había indicios del fallo de memoria en una auditoría de 2024, pero la solución quedó bloqueada durante meses, un retraso que calificó de «fallo 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 esta solución. Para un sitio alojado en un servidor compartido, el último paso es abrir un ticket de soporte.

Etiquetas: wordpress, Cloudflare, PHP, PHP2Shell, vulnerabilidades