php2shell: con qué rapidez cerraron los hostings la vulnerabilidad crítica de PHP

El 20 de octubre, el proyecto PHP anunció para el día siguiente una versión de seguridad crítica, a las 14:00 UTC. El 21 de octubre, a las 16:00 h, hora alemana, estaban disponibles PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Lo que ocurre después ya no está, para la mayoría de quienes gestionan una web, en sus manos: quien usa hosting compartido o WordPress gestionado es vulnerable hasta que el proveedor lleva la actualización a sus servidores.

Mantenemos varios sitios web y aplicaciones en distintos proveedores de hosting, propios y de clientes. De 27 de ellos fuimos anotando aquella tarde cuándo llegaba la nueva versión. El resultado no es una prueba comparativa de hostings, pero sí una mirada honesta a lo distinto que es el ritmo de unos a otros.

Qué es php2shell

Según el aviso de seguridad del proyecto PHP, detrás del nombre hay dos errores en el manejo de la memoria entre dos peticiones. En CVE-2026-109618, una interrupción por falta de memoria puede dejar datos a medio terminar que PHP, al limpiar, da por válidos. En CVE-2026-109619 queda en memoria el estado interno de una petición después de que su memoria ya se ha liberado, y la siguiente petición del mismo proceso accede a él. Ambas están valoradas con CVSS 9.2 y, en el peor caso, permiten ejecutar código propio en el servidor.

Está afectada toda instalación de PHP que atiende peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo es más alto con mod_php. El atacante no necesita iniciar sesión, y el ataque actúa antes de que WordPress o un plugin ejecuten siquiera código. Un plugin de seguridad, por tanto, no ve nada de esto.

Hasta qué punto ya hay ataques en marcha lo valoran las fuentes de forma distinta. El Cyber Centre canadiense informó el 21 y el 23 de octubre de una prueba de concepto pública, pero de ninguna explotación constatada todavía (aviso AL26-026). Según Help Net Security, Amazon vio un intento de explotación ya el 17 de octubre, cuatro días antes de la publicación.

Nuestra medición: 27 sistemas, siete proveedores y un servidor propio

Medimos desde fuera y solo en modo lectura. La mayoría de los proveedores indican la versión de PHP en la cabecera de respuesta X-Powered-By. La consultamos cada cinco minutos en Hostinger y STRATO, y lo hicimos en wp-login.php, porque esa página nunca sale de la caché y PHP se ejecuta seguro. En Raidboxes, la versión figuraba en el informe del sistema de WooCommerce. All-Inkl oculta la cabecera de respuesta; allí un archivo de prueba de una sola línea mostró la versión y se borró enseguida. En united-domains y CheckDomain, la versión no se podía leer desde fuera.

Hay que hacer dos salvedades. Medimos nuestras propias cuentas, no una muestra de todos los servidores de un proveedor. Los grandes proveedores suelen desplegar las actualizaciones servidor por servidor, así que otros clientes pueden haber recibido el parche antes o después. Y entre el 22 y el 26 de octubre no medimos en Hostinger, de modo que no sabemos cuándo llegó exactamente la 8.3.36.

Lo que sacamos en claro

El margen es amplio y no se ve

Entre el hosting más rápido y el más lento de nuestra medición hay al menos 13 horas, toda una noche. Desde fuera no se nota si el servidor de una web ya está parcheado. Quien no lo comprueba, no lo sabe.

Un servidor propio es tan rápido como su paso más lento

En nuestro servidor propio corre una aplicación en Docker, construida sobre la imagen oficial de PHP. La imagen con el número 8.4.27 apareció a las 17:45 h; la versión para los servidores Intel y AMD habituales, solo a las 18:47 h. Nuestra reconstrucción se ejecutó a las 18:51 h. Para que descargara la nueva imagen base y no tomara la antigua de la caché, tuvimos que modificar las instrucciones de construcción. Desde entonces, cada build trae la imagen actual.

Coolify, la plataforma con la que gestionamos ese servidor, publicó su actualización con la versión de PHP parcheada solo doce minutos después de la publicación. Aun así, a nosotros solo nos llegó con la actualización automática nocturna. Los fabricantes rápidos sirven de poco si la actualización se queda parada en tu sistema.

Las ramas antiguas de PHP ya no reciben nada

Un sistema seguía en PHP 8.1. Para 8.1 y anteriores, el proyecto PHP ya no publica versiones; solo hay correcciones mínimas en el código fuente para quienes compilan PHP ellos mismos. En hosting compartido, ahí solo ayuda pasar a una rama con soporte. Otro sistema ya estaba, antes de la versión de seguridad, cinco versiones por detrás: en 8.2.29 en lugar de 8.2.34. La buena noticia: la versión de seguridad también lo puso al día, y en la nueva medición funcionaba con 8.2.35.

Sin PHP no hay vulnerabilidad de PHP

Nuestra web principal, hafenstudios.com, no estaba afectada porque consiste en archivos HTML estáticos. Para un sitio WordPress eso no es una opción, pero muestra por qué las partes que no necesitan PHP tampoco deberían ejecutarlo.

Cómo comprobar tu versión de PHP en WordPress

1. En el escritorio: Herramientas → Salud del sitio, pestaña Información, y despliega la sección Servidor. Ahí figura la versión de PHP con la que WordPress se está ejecutando.
2. Compárala con la tabla: tu rama está parcheada a partir del número de la columna «Parcheada desde».
3. Leer bien los añadidos: detrás del número puede haber una sigla del proveedor, por ejemplo 8.3.36-nmm1. Lo que cuenta es el número anterior.

Una excepción: algunas distribuciones de Linux y algunos proveedores incorporan la corrección a su propia versión sin cambiar el número. Si ves un número más antiguo y tu proveedor dice que ha parcheado, no hay contradicción. Entonces vale su confirmación por escrito.

Quien gestiona muchas webs puede consultar también, a partir de WordPress 6.9, la interfaz REST, con una contraseña de aplicación y solo en modo lectura: /wp-json/wp-abilities/v1/abilities/core/get-environment-info/run devuelve, entre otras cosas, la versión de PHP.

Si tu hosting aún no ha parcheado

• Preguntar. Basta una frase al soporte: ¿cuándo llega PHP 8.x.y con la corrección para CVE-2026-109618 y CVE-2026-109619? La respuesta también te dice con qué seriedad se lo toma tu proveedor.
• Cambiar de rama. Muchos proveedores ofrecen varias versiones de PHP a elegir. Si otra rama ya está parcheada, puedes cambiarte a ella después de una prueba breve. Antes, una copia de seguridad; después, recorre la página de inicio, el inicio de sesión y los formularios.
• Un firewall como puente. Cloudflare ha desplegado reglas contra las vías de ataque conocidas, también en el plan gratuito. Pero el proyecto PHP escribe con claridad que no existe una mitigación completa. El firewall no sustituye a la actualización.
• En servidores propios: actualiza los paquetes, reconstruye los contenedores con una imagen base nueva y reinicia después todos los procesos de PHP. Los ajustes con los que el proyecto PHP permite cubrir el tiempo hasta la actualización figuran en el aviso de seguridad.

El 23 de octubre se añadió una adenda: una tercera vulnerabilidad, CVE-2026-115560, está en el indicador de progreso de las cargas en las sesiones. Solo actúa si una aplicación cambia en tiempo de ejecución el formato de almacenamiento de sus sesiones de PHP. WordPress no usa sesiones de PHP; en todo caso, entrarían en juego plugins que sí lo hagan. La corrección llegará con la siguiente versión regular y, hasta entonces, el proyecto PHP recomienda session.upload_progress.enabled=0. En hosting compartido, eso solo lo puede configurar el proveedor.

Y si de todos modos estás poniendo orden: las actualizaciones de PHP son solo una mitad. Por qué los plugins obsoletos son el problema más duradero lo explicamos en nuestro artículo sobre cómo actualizar los plugins de WordPress. Lo anticuados que siguen siendo en parte los requisitos mínimos del directorio de plugins lo muestra nuestro análisis: 8.131 plugins siguen indicando PHP 5 (en inglés).

Preguntas frecuentes