En resumen: tras PHP2Shell, la versión de PHP que se muestra demuestra poco por sí sola, porque los proveedores de hosting suelen incorporar las correcciones como backport. Por eso, pida por escrito una confirmación de actualización de PHP al hosting: estado de los paquetes de cada rama de PHP, momento de la instalación y reinicio de todos los procesos de PHP. Más abajo encontrará una plantilla para copiar.
Por qué ahora cuenta una confirmación por escrito
El 21/10/2026 el proyecto PHP publicó los parches para dos vulnerabilidades críticas conocidas como PHP2Shell. Ambas permiten ejecutar código malicioso de forma remota y sin autenticación. El BSI (Oficina Federal alemana para la Seguridad de la Información) ha declarado el nivel de alerta 3 / naranja y recomienda la actualización inmediata.
Quien aloja su sitio web en un proveedor de hosting a menudo no puede instalar la actualización por sí mismo. Al mismo tiempo, usted, como responsable del sitio, responde de los datos de sus clientes. Una confirmación escrita y concreta del proveedor es, por tanto, algo más que una formalidad. Es una pieza de su documentación, por ejemplo frente a los delegados de protección de datos, las aseguradoras o la dirección.
A ello se suma que un parche no elimina el software malicioso que se haya introducido antes. Según informes de los medios, ya el 17/10 se observó un primer intento de ataque. El momento exacto en que su servidor quedó protegido es, por eso, importante para decidir si debe seguir revisando.
Por qué no basta con la versión de PHP que se muestra
Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Sin embargo, muchas distribuciones y proveedores de hosting incorporan la corrección como backport en su propio paquete. En ese caso, un panel como Plesk sigue mostrando 8.2.34 aunque el servidor esté parcheado.
A la inversa, un número de versión correcto también puede engañar. Los archivos nuevos por sí solos no protegen mientras sigan ejecutándose procesos de PHP antiguos en memoria. Solo después de reiniciar todos los workers queda activo el nuevo estado. Más información en el artículo Cómo comprobar bien la versión de PHP y el estado del parche.
| Afirmación del proveedor | Qué demuestra | Qué falta |
|---|---|---|
| «Todos los sistemas están actualizados.» | poco | Versión o estado del paquete, fecha, reinicio |
| «PHP 8.3.36 está instalado.» | Versión | Fecha, reinicio, servidores afectados |
| «Backport en el paquete xy, reinicio el …» | Parche y activación | En su caso, datos sobre PHP 8.1 y anteriores |
Qué datos necesita del proveedor de hosting
Pida respuestas a estos puntos, a ser posible para cada sitio web o contrato:
- ¿Qué ramas y versiones de PHP están activas para sus sitios web, incluidas las más antiguas que se ejecutan solo en directorios concretos?
- ¿Incluyen las correcciones de CVE-2026-109618 y CVE-2026-109619, como versión oficial o como backport?
- ¿Cuándo se instaló la actualización y cuándo se reiniciaron todos los procesos de PHP (pools de FPM, Apache, LiteSpeed)?
- ¿Está desactivado
session.upload_progress.enableda causa de CVE-2026-115560? - ¿Qué modo de ejecución usa su tarifa, por ejemplo PHP-FPM o Apache con mod_php? Con mod_php, el equipo de PHP ve el mayor riesgo.
- ¿Qué registros de acceso y de errores desde el 20/10/2026 se conservan y cómo puede obtenerlos?
Si un sitio web todavía funciona con PHP 8.1 o anterior, pregunte por separado. Para estas ramas ya no hay actualizaciones oficiales, solo backports mínimos del código fuente para 7.4, 8.0 y 8.1.
Plantilla: solicitar la confirmación de actualización de PHP al hosting
Copie el texto en un ticket de soporte o en un correo a su proveedor de hosting. Complete los datos entre corchetes.
Asunto: Solicitud de confirmación del estado de los parches de PHP (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Buenos días:
operamos con ustedes los siguientes sitios web / contratos:
[número de cliente, contrato, dominios]
En relación con las vulnerabilidades de PHP CVE-2026-109618 y
CVE-2026-109619 (PHP2Shell, parches del 21.10.2026) y con el aviso
sobre CVE-2026-115560 del 23.10.2026, les solicitamos una
confirmación por escrito de los siguientes puntos:
1. ¿Qué versiones de PHP o estados de paquetes están activos para nuestros sitios web?
2. ¿Incluyen las correcciones (versión oficial o backport)?
3. Fecha y hora de la instalación.
4. Fecha y hora del reinicio de todos los procesos de PHP (FPM, Apache,
LiteSpeed o similares).
5. ¿Está session.upload_progress.enabled desactivado en el servidor?
6. ¿Qué modo de ejecución de PHP se utiliza (p. ej. PHP-FPM, mod_php)?
7. ¿Se conservan los registros de acceso y de errores a partir del 20.10.2026 y
cómo podemos obtenerlos?
8. Si algún sitio web aún usa PHP 8.1 o anterior: ¿qué protección
existe allí y qué migración recomiendan?
Necesitamos estos datos para nuestra documentación interna.
Muchas gracias y un cordial saludo
[Nombre, empresa, cargo]
Valorar la respuesta y contrastarla por su cuenta
Una buena respuesta indica estados, fechas y horas concretos. Fórmulas generales como «hemos reaccionado» no bastan para su expediente. En ese caso, pregunte con cortesía por los puntos que faltan.
Si su tarifa lo permite, compruébelo además usted mismo. Con acceso por SSH, normalmente bastan estos comandos:
# Versión de la línea de comandos (puede diferir de la versión web)
php -v
# Estado de los paquetes en Debian/Ubuntu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Estado de los paquetes en RHEL, Alma, Rocky
rpm -qa | grep -i php
# ¿Desde cuándo se ejecutan los procesos de PHP-FPM?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Si la hora de inicio de los procesos de PHP es anterior a la fecha de instalación confirmada, el reinicio no fue completo.
Si el proveedor no responde o responde con evasivas
Si no llega respuesta o faltan los datos decisivos, no debería dar la situación por aclarada. El BSI recomienda desconectar temporalmente los servidores web de la red cuando no es posible actualizar de inmediato. Si eso es proporcionado para su sitio web lo decide la dirección, idealmente por escrito y con fecha.
En paralelo, conviene buscar posibles rastros de un ataque, porque el momento del parche sigue abierto. El artículo ¿Ya me han comprometido? ofrece indicios. Sin acceso por SSH, la confirmación escrita sigue siendo su prueba más importante. Qué obligaciones corresponden al proveedor y cuáles a usted lo explica la página Hosting compartido: qué hace el proveedor; para servidores gestionados sirve Servidor gestionado: aclarar la responsabilidad.
Guarde en una carpeta, con su fecha, la consulta, la respuesta y los resultados de sus propias comprobaciones. Este expediente ayudará más adelante ante las preguntas de aseguradoras o delegados de protección de datos.
¿Cómo ayuda PHP SOS en concreto?
- Redactamos con usted la consulta al proveedor de hosting y valoramos técnicamente la respuesta.
- Donde hay acceso, comprobamos nosotros mismos el estado de los paquetes, el modo de ejecución activo y el reinicio de los procesos de PHP.
- Si quedan lagunas, aplicamos medidas transitorias o planificamos la migración a una versión con soporte.
- Dejamos constancia del resultado y de los momentos en un justificante que usted puede compartir internamente.
Cómo se desarrolla la actualización con reinicio y justificante lo describe nuestro servicio de parches de PHP.
Preguntas frecuentes
¿Basta con que mi proveedor de hosting escriba que todo está actualizado?
Para su documentación, probablemente no. Pida datos concretos: estado de los paquetes o versión de cada rama de PHP, fecha de la instalación y fecha del reinicio de todos los procesos de PHP. Solo con eso podrá acotar la ventana de tiempo de la vulnerabilidad.
¿Por qué mi panel de hosting sigue mostrando PHP 8.2.34?
Las distribuciones y los proveedores de hosting incorporan a veces las correcciones de seguridad como backport sin cambiar el número de versión. Plesk puede seguir mostrando 8.2.34 aunque el servidor esté parcheado. Solo la confirmación del proveedor sobre el estado de los paquetes aclara la situación.
¿Qué hago si el proveedor de hosting no responde?
Documente su consulta con la fecha y vuelva a preguntar pasado un plazo razonable. Compruebe en paralelo si puede aplicar usted mismo medidas transitorias y acuerde con la dirección si el sitio web se desconecta de la red hasta que se aclare la situación, como recomienda el BSI para los servidores sin parchear.
¿Cierra la vulnerabilidad también una actualización de WordPress o de la tienda?
No. PHP2Shell reside en el propio PHP. Actualizar el CMS o el software de la tienda no cambia nada en el intérprete de PHP que se ejecuta en el servidor.