En resumen: ante una vulnerabilidad de PHP como PHP2Shell, en el hosting web el responsable de actualizar PHP es el proveedor, no usted. Su tarea es obtener una confirmación por escrito, elegir en el menú de cliente una versión de PHP compatible y revisar su sitio web en busca de rastros de un ataque. Un parche del proveedor no elimina el software malicioso que haya llegado antes a su sitio web.
La situación en palabras sencillas
PHP es el lenguaje de programación con el que funcionan la mayoría de los sitios web, tiendas online y CMS como WordPress. PHP2Shell designa dos fallos críticos en el propio PHP (CVE-2026-109618 y CVE-2026-109619). A través de ellos, los atacantes pueden ejecutar su propio código en el servidor sin contraseña. El BSI (Oficina Federal Alemana de Seguridad de la Información) ha declarado el nivel de alerta 3 (naranja) y recomienda actualizar de inmediato.
En el hosting compartido, muchos clientes comparten un servidor. La tecnología subyacente, es decir, el sistema operativo, el servidor web y PHP, la opera el proveedor. Usted solo gestiona su sitio web, su base de datos y sus accesos. Por eso no puede instalar usted mismo la actualización de PHP, y tampoco tiene que hacerlo.
Hosting y vulnerabilidad de PHP: ¿quién es responsable?
El reparto se deriva de su contrato. En la mayoría de las tarifas rige, a grandes rasgos, la siguiente distribución:
| Tarea | Proveedor | Usted como cliente |
|---|---|---|
| Actualizar los paquetes de PHP | sí | no |
| Reiniciar los procesos PHP | sí | no |
| Fijar valores provisionales en todo el servidor | sí | no |
| Elegir la versión de PHP de su sitio web | la pone a disposición | la elige |
| Actualizar CMS, plugins y temas | no | sí |
| Credenciales y cuentas de administrador | no | sí |
| Revisar el sitio web en busca de código malicioso | en parte | sí |
| Valoración en materia de protección de datos | no | sí |
Lo importante es la última fila: si en su sitio web se produce un incidente con datos personales, por lo general el responsable es usted como operador, no el proveedor. Más información en Obligación de notificar según el RGPD.
Qué debería hacer usted ahora
1. Obtener la confirmación. Pregunte por escrito a su proveedor si las versiones de PHP de su paquete están protegidas frente a ambas CVE, desde cuándo, y si se han reiniciado todos los procesos PHP. Encontrará una plantilla lista en Preguntar al hosting por el estado del parche. No se extrañe si en el menú de cliente sigue figurando un número de versión más antiguo, como 8.2.34: algunos proveedores entregan las correcciones como backport sin que el número cambie.
2. Comprobar la versión de PHP. Consulte en el menú de cliente qué versión de PHP usa su sitio web. PHP 8.1 y anteriores ya no reciben actualizaciones oficiales del proyecto PHP. PHP 8.2 llega al final del soporte el 31/12/2026. Si su CMS admite una versión más reciente, compruébelo en los requisitos del sistema del fabricante, por ejemplo en wordpress.org.
3. Controlar el sitio web. Esté atento a cuentas de administrador desconocidas, redirecciones inesperadas, archivos ajenos en el acceso FTP y avisos en Google Search Console. En ¿Ya estoy comprometido? encontrará una lista de señales típicas.
4. Hacer una copia de seguridad. Descargue una copia actual de los archivos y de la base de datos y guárdela por separado. Pida además al proveedor que conserve los registros de acceso de su paquete desde el 20/10/2026.
Una vez que el proveedor haya confirmado, cambie por precaución las contraseñas del menú de cliente, de FTP/SFTP, de la base de datos y de los administradores del CMS, y active la autenticación en dos factores donde sea posible.
Lo que no puede resolver usted mismo en el hosting compartido
Las medidas provisionales recomendadas por php.net, por ejemplo session.upload_progress.enabled=0, solo funcionan si se fijan en la configuración del servidor. Según php.net, una entrada en .user.ini o mediante ini_set() en el código no basta. También los límites de memoria a nivel de cgroup y el reinicio de los procesos PHP son competencia del proveedor.
Si su proveedor no responde o lo hace con evasivas, tiene tres opciones: insistir y fijar un plazo, poner temporalmente el sitio web en modo de mantenimiento o cambiar a un proveedor que dé una respuesta clara. El BSI recomienda desconectar temporalmente de la red los servidores web si no es posible actualizar de inmediato.
Compruebe además si su tarifa sigue siendo actual. Los paquetes que llevan muchos años funcionando sin cambios a veces están en generaciones de servidores más antiguas, con versiones de PHP anteriores que el proveedor solo mantiene de forma limitada. Pasar a una tarifa actual del mismo proveedor suele suponer poco esfuerzo e incluye versiones de PHP más recientes. Pregúntelo si la respuesta sobre el estado del parche no le satisface.
Si el sitio web ya presenta anomalías
Un parche del proveedor cierra la vulnerabilidad de cara al futuro. Sin embargo, no elimina una puerta trasera que los atacantes hayan instalado antes ni demuestra que antes no haya pasado nada. Si encuentra anomalías, no borre archivos al azar. Asegure primero el estado, para que la causa pueda reconstruirse más adelante.
¿Cómo ayuda PHP SOS en concreto?
- Redactamos con usted la consulta al proveedor y valoramos técnicamente su respuesta.
- Revisamos su sitio web en busca de webshells, cuentas ajenas y archivos manipulados y, si hay hallazgos, lo limpiamos mediante nuestra eliminación de malware.
- Ante una sospecha aguda asumimos la ayuda de emergencia para sitios web hackeados, con preservación de pruebas.
- Le ayudamos a elegir una versión de PHP adecuada y probamos después el sitio web.
Preguntas frecuentes
Como cliente de hosting, ¿tengo que actualizar PHP yo mismo?
Por lo general no, porque en el hosting compartido PHP forma parte de la plataforma del proveedor. Sin embargo, en el menú de cliente suele poder elegir la versión de PHP. Si allí figura una versión sin actualizaciones oficiales, debería cambiar o preguntar al proveedor cómo la protege.
Mi sitio web está fuera de línea. ¿Me han hackeado?
No necesariamente. Algunos proveedores han desconectado sitios web de la red como medida preventiva para cerrar la vulnerabilidad. Pregunte al proveedor el motivo y pídale que le confirme si hay indicios de un ataque a su paquete.
¿Puedo fijar yo mismo las medidas provisionales en .user.ini?
Para session.upload_progress.enabled, php.net indica expresamente que .user.ini e ini_set() no son suficientes. Esta opción tiene que fijarla el proveedor en la configuración del servidor.
¿Qué debería tener por escrito del proveedor?
Una confirmación de que las versiones de PHP de su paquete están protegidas frente a CVE-2026-109618 y CVE-2026-109619, desde cuándo, y de que los procesos PHP se han reiniciado. Conserve esta respuesta junto con su documentación.