El 21 de octubre de 2026, los proveedores de hosting tuvieron que parchear PHP a contrarreloj.
El nombre php2shell agrupa dos vulnerabilidades críticas de PHP, registradas en el catálogo CVE como CVE-2026-109618 y CVE-2026-109619, que se hicieron públicas ese día. Los dos fallos permitían ejecutar código de forma remota en el servidor y, desde ahí, comprometer las webs que aloja.
Los primeros intentos de ataque se detectaron varios días antes de que hubiera una solución oficial. Unos proveedores llegaron al 21 con mitigaciones activas; otros dejaron el parche de los VPS en manos del cliente.
Si vas a contratar un VPS, pregunta hasta dónde llega la responsabilidad del proveedor en seguridad, quién actualiza PHP y qué hace cuando aparece un fallo de esta gravedad.
Cuatro días de incertidumbre hasta la publicación del parche
El 17 de octubre, Amazon identificó intentos de explotación relacionados con las vulnerabilidades que terminarían haciéndose públicas cuatro días después.
Los detalles habían empezado a circular antes de que terminara el embargo acordado para su divulgación, de manera que los atacantes pudieron actuar mientras los proveedores seguían esperando el parche.
Durante la mañana del 21 de octubre ya se estaban registrando intentos de explotación a gran escala. La actualización oficial llegó hacia las 14:00 UTC con las versiones PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen las dos vulnerabilidades.
El problema estaba en PHP y afectaba directamente al hosting
El fallo de php2shell estaba en el propio intérprete PHP, que ejecuta buena parte de las aplicaciones web actuales. Por tanto, una página de WordPress podía tener todos sus plugins actualizados, utilizar una plantilla segura y seguir expuesta.
En un hosting compartido o gestionado, actualizar PHP corresponde normalmente a la empresa que presta el servicio. El propietario de la web depende de lo que haga su proveedor.
Con los VPS la situación cambia. Si el servidor está contratado sin administración, suele ser el cliente quien debe instalar las actualizaciones.
Qué podían hacer los proveedores antes del 21 de octubre
Sin un PHP corregido publicado, las medidas fueron los cortafuegos de aplicaciones web, conocidos como WAF, las reglas específicas de los servidores y algunos ajustes de seguridad mediante php.ini.
Un WAF bloquea las peticiones que tienen la forma de un ataque conocido, y las reglas del servidor cortan las que intentan llegar al componente vulnerable.
Otra medida provisional fue desactivar el seguimiento del progreso de subida de archivos con la directiva session.upload_progress.enabled = Off, que el aviso de PHP recomendaba contra CVE-2026-109619. El cambio va en el php.ini que usa el servidor web, no en el de la terminal.
Estas medidas pueden detener ataques conocidos, pero su eficacia depende de cómo se hayan configurado y de las técnicas que empleen los delincuentes.
Mitigar reduce la exposición mientras llega el parche; parchear corrige el fallo en PHP.
Cloudflare, SiteGround, Hostinger y GoDaddy ante php2shell
Cloudflare fue una de las primeras en activar protecciones generalizadas. El 21 de octubre, a las 3:02 UTC, habilitó por defecto reglas WAF destinadas a bloquear los ataques relacionados con php2shell. La protección alcanzó también a los usuarios de su plan gratuito.
SiteGround había preparado mitigaciones para todos sus servidores horas antes de que aparecieran las actualizaciones oficiales. La compañía desactivó las funciones afectadas en todas las versiones de PHP que mantiene y, cuando salieron las correcciones, las instaló en sus servidores.
Hostinger aplicó bloqueos preventivos y ajustes de seguridad mientras esperaba los paquetes corregidos. El despliegue de los parches en sus servicios gestionados terminó el 22 de octubre a las 06:44 UTC. En los VPS, sin embargo, la instalación le tocaba a cada cliente.
GoDaddy actualizó su servicio de WordPress gestionado y mantuvo medidas de mitigación en otros alojamientos hasta disponer de las correcciones correspondientes. Los clientes con VPS sin administración debían encargarse de actualizar sus sistemas.
En el mercado español, Factoría Digital, según la propia empresa, extendió las mitigaciones también a sus VPS sin administración mientras llegaba el parche, y el 22 de octubre instaló los paquetes corregidos.
Cómo saber si PHP está parcheado en tu servidor
Pasada la emergencia, habla con el proveedor. La primera pregunta es si se han aplicado las correcciones de ambas vulnerabilidades y cuándo se instalaron.
Pregunta también por CVE-2026-115560, una tercera falla que PHP publicó el 23 de octubre y que afecta al progreso de subida de las sesiones. PHP considera poco probable que permita ejecutar código de forma remota y la corrige en su ciclo normal de versiones; hasta entonces, recomienda la misma directiva session.upload_progress.enabled = Off.
Y si el proveedor mantiene versiones de PHP que ya terminaron su soporte oficial, pregúntale cómo las corrigió: para esas ramas PHP no publicó versiones nuevas, solo parches mínimos de código.
Pide además una prueba de la actualización. Consultar únicamente el número de versión de PHP puede llevar a conclusiones equivocadas, ya que distribuciones como Debian o Ubuntu incorporan parches de seguridad a versiones anteriores.
La fecha de compilación, la revisión del paquete instalado y su historial de cambios ofrecen información más fiable.
En un VPS con Debian o Ubuntu, puedes comprobarlo así (sustituye 8.3 por tu versión de PHP):
php -v
dpkg -l | grep php8.3
zgrep -iE "CVE-2026-109618|CVE-2026-109619" /usr/share/doc/php8.3-common/changelog.Debian.gz
Ten en cuenta que php -v muestra la versión de PHP de la terminal, que no siempre coincide con la que usa el servidor web.
Si el último comando devuelve líneas con los CVE, el historial del paquete registra la corrección; comprueba que esa entrada corresponda a la revisión instalada que muestra el segundo comando.
Si no aparece nada, no significa que falte el parche: algunos repositorios no anotan los CVE en el historial.
En ese caso, la versión sirve en un solo sentido: desde la 8.3.36 (o la 8.5.12, 8.4.27 o 8.2.35 en las otras ramas) el parche ya viene incluido; por debajo, no prueba nada y toca preguntar al proveedor si aplicó la corrección retroportada.
En php2shell, la diferencia la marcó quién instalaba el parche: el proveedor en el hosting gestionado, el cliente en el VPS sin administración.