En resumen: en un servidor gestionado, el proveedor asume una parte de la seguridad, normalmente el sistema operativo, los paquetes de PHP y los servicios estándar. La aplicación, los plugins, los accesos y la responsabilidad en materia de protección de datos suelen quedar en sus manos. Tras PHP2Shell debería aclarar ambas cosas por escrito: qué ha hecho el proveedor y qué sigue en su ámbito.
Qué significa «gestionado» y qué no
El término no está protegido. Un proveedor puede entender con él únicamente la instalación de actualizaciones del sistema operativo; otro atiende también el servidor web, PHP, la base de datos y las copias de seguridad. Algunas tarifas incluyen supervisión las 24 horas; otras, solo un interlocutor en horario comercial.
Justo en una situación como PHP2Shell se ve lo precisa que es la descripción del servicio. Las dos vulnerabilidades CVE-2026-109618 y CVE-2026-109619 están en el propio PHP. Si su proveedor mantiene PHP como parte de su plataforma o si PHP cuenta como «su software», consta en el contrato. No se fíe de la suposición de que alguien ya se está ocupando.
Seguridad de un servidor gestionado: reparto habitual de tareas
La tabla siguiente muestra un reparto frecuente. No sustituye la lectura de su contrato, pero ayuda a plantear las preguntas adecuadas.
| Ámbito | Normalmente el proveedor | Normalmente usted |
|---|---|---|
| Hardware, red, virtualización | sí | no |
| Actualizaciones del sistema operativo | sí | no |
| Paquetes de PHP de la plataforma | a menudo | si los instaló usted |
| Reinicio de PHP-FPM y del servidor web | a menudo | en servicios propios |
| Configuración de PHP de todo el servidor | a menudo | en caso de deseos especiales |
| CMS, tienda, plugins, código propio | no | sí |
| Cuentas de administrador de la aplicación | no | sí |
| Copias de seguridad | con frecuencia | comprobar la restauración |
| Valoración y notificación de brechas de datos | no | sí |
| Supervisión frente a ataques | según la tarifa | según la tarifa |
Los campos poco claros son el verdadero riesgo. Donde tendría que escribir «según la tarifa» o «a menudo», falta una regulación.
Qué preguntas debería plantear ahora
Envíe a su proveedor una consulta breve y objetiva. Pida la respuesta por escrito, para poder presentarla más adelante. Debería incluir estos puntos:
- ¿Qué versiones de PHP funcionan en nuestro servidor y están protegidas frente a CVE-2026-109618 y CVE-2026-109619?
- ¿Desde cuándo es así y se reiniciaron después todos los procesos PHP y el servidor web?
- ¿Se instaló la corrección como backport? Si es así, ¿qué versión del paquete lo demuestra?
- ¿Hubo indicios de intentos de ataque o de procesos anómalos en nuestro servidor?
- ¿Se conservan los registros del servidor web desde el 20/10/2026 y cómo los obtenemos?
Encontrará una plantilla redactada en Preguntar al hosting por el estado del parche. El número de versión del menú de cliente no es una prueba: con los backports suele permanecer sin cambios, por ejemplo en 8.2.34.
Aunque el proveedor haya parcheado PHP, su aplicación sigue necesitando una revisión. Un parche no elimina el software malicioso introducido antes de la actualización y no demuestra que no haya pasado nada.
Lo que sigue en sus manos
Su parte abarca sobre todo la aplicación. Compruebe que el CMS, la tienda y los plugins están actualizados, elimine las extensiones que ya no se usen y controle la lista de administradores. Esté atento a archivos nuevos en las carpetas de cargas, redirecciones ajenas y tareas programadas inusuales en la aplicación.
A ello se suma el aspecto jurídico. Si en un incidente llegan datos personales a manos ajenas, por lo general es su empresa, como responsable del tratamiento, la que está obligada a notificar, no el proveedor. Este, como encargado del tratamiento, debe informarle sin demora. Los fundamentos se explican en Obligación de notificación del RGPD: 72 horas. Se trata de información general, no de asesoramiento jurídico; el caso concreto lo valoran los delegados de protección de datos o los abogados.
Hay otro punto que a menudo se pasa por alto: el software que usted o su agencia hayan instalado en el servidor gestionado, por ejemplo una versión adicional de PHP de una fuente externa, un contenedor o un programa auxiliar, normalmente no entra en el mantenimiento del proveedor. Pregunte, por tanto, si el proveedor sabe qué funciona además del equipamiento estándar. Y aclare quién asume la investigación en caso de sospecha. Muchos proveedores restauran la plataforma, pero no investigan si se vieron afectados datos ni cuáles. Y esa es justo la respuesta que usted necesita para valorar posibles obligaciones de notificación.
Mejorar los contratos para el futuro
Aproveche la situación para dejar fijado el reparto de tareas. Son útiles las cláusulas sobre actualizaciones de seguridad, incluido el reinicio, sobre la información en caso de vulnerabilidades críticas, sobre la conservación y entrega de registros y sobre el apoyo en caso de incidentes. Pregunte también si el proveedor le avisa de forma activa o si tiene que preguntar usted mismo.
Un servidor propio sin mantenimiento es la alternativa, pero traslada todo el trabajo a su lado. Qué significa eso se describe en Proteger por su cuenta un servidor root y un vServer.
¿Cómo ayuda PHP SOS en concreto?
- Leemos la descripción de su servicio y elaboramos una matriz de tareas que hace visibles las lagunas.
- Redactamos las preguntas técnicas a su proveedor y valoramos sus respuestas.
- Revisamos la parte de aplicación que está en su ámbito en busca de rastros y componentes obsoletos.
- Lo que el proveedor no cubra, lo asumimos si lo desea mediante un contrato de mantenimiento de seguridad o lo complementamos con monitorización de seguridad.
Preguntas frecuentes
¿Está todo protegido automáticamente en un servidor gestionado?
No. Gestionado significa que el proveedor asume determinadas tareas fijadas por contrato, normalmente el sistema operativo y los servicios estándar. La aplicación, los plugins, los accesos y el software propio suelen seguir en sus manos.
¿Dónde consta de qué se encarga mi proveedor?
En la descripción del servicio y en las condiciones contractuales, a menudo también en un documento sobre el reparto de tareas. Si hay datos personales, se suma el contrato de encargo del tratamiento. Si falta una regulación clara sobre las actualizaciones de seguridad, pregunte por escrito.
A pesar de tener un servidor gestionado, ¿tengo que hacer algo yo por PHP2Shell?
Sí. Obtenga una confirmación de que todas las versiones de PHP están parcheadas y los procesos reiniciados. Revise además su aplicación en busca de rastros y aclare si existe obligación de notificar.
¿Quién notifica una brecha de datos si el proveedor de hosting se vio afectado?
Quien está obligado a notificar a la autoridad de control es, por lo general, el responsable del tratamiento, es decir, su empresa. El proveedor de hosting, como encargado del tratamiento, debe informarle sin demora. Pida a su delegado de protección de datos que valore el caso concreto.