En resumen: ¿Qué hacer como cliente de alojamiento ante la vulnerabilidad de PHP PHP2Shell? La actualización de PHP normalmente no tiene que aplicarla usted; en el alojamiento compartido se encarga el proveedor. Sus tareas son otras: obtener una confirmación escrita del nivel de parcheo, elegir en el menú de cliente una versión de PHP compatible y revisar su sitio web en busca de anomalías. Este artículo responde a las 15 preguntas más frecuentes de forma breve y por orden.
Vulnerabilidad de PHP para clientes de alojamiento: ¿estoy afectado, qué hago?
Desde el 21 de octubre de 2026 recibimos muchas preguntas de empresas cuyo sitio web está en un proveedor de alojamiento. La mayoría giran en torno a los mismos puntos. Quien quiera leer las responsabilidades con más detalle las encontrará en Alojamiento compartido: qué hace el proveedor y qué debe hacer usted.
1. ¿Está afectado mi sitio web?
Si su sitio web funciona con WordPress, Shopware, TYPO3, Joomla, Contao u otro sistema PHP, el servidor que hay debajo puede estar afectado. Las páginas HTML puras sin PHP no lo están. En caso de duda ayuda echar un vistazo al menú de cliente: si hay allí un ajuste para la versión de PHP, usted usa PHP.
2. ¿Qué diferencia hay entre alojamiento compartido y servidor propio?
En el alojamiento compartido usted comparte con otros clientes un servidor operado por el proveedor; el proveedor mantiene PHP. En un servidor root o vServer propio, la responsabilidad es suya. En un servidor gestionado, el contrato regula quién aplica las actualizaciones.
3. Mi proveedor ha enviado un correo masivo. ¿Tengo que hacer algo más?
Lea con atención lo que dice. Un correo masivo a menudo solo confirma que el proveedor «está trabajando en el asunto». Usted necesita una declaración sobre su paquete: rama de PHP, nivel de parcheo, momento y reinicio.
Responsabilidad y actualización
4. ¿Aplica el proveedor la actualización automáticamente?
Por lo general sí, para las versiones de PHP que ofrece en sus servidores. Si ya ha ocurrido y si también están cubiertas las versiones más antiguas varía de un proveedor a otro. Pregunte.
5. Mi menú de cliente muestra un número de versión antiguo. ¿Estoy desprotegido?
No necesariamente. Muchos proveedores incorporan las correcciones como backport y el número se mantiene. Plesk, por ejemplo, puede seguir mostrando 8.2.34 aunque el fallo esté corregido. Lo que vale es la confirmación del proveedor.
6. Todavía uso PHP 7.4 o 8.1. ¿Qué hago ahora?
Estas ramas ya no reciben actualizaciones oficiales del proyecto PHP. Algunos proveedores entregan correcciones propias y otros no. Aclárelo por escrito y planifique el cambio a una rama compatible. Compruebe antes en los requisitos del sistema de su CMS qué versiones de PHP admite.
7. ¿Puedo cambiar yo mismo la versión de PHP?
En la mayoría de los proveedores sí, en el menú de cliente. Cómo se hace y a qué debe prestar atención antes lo describe el artículo Cambiar la versión de PHP en el área de cliente del alojamiento. Haga antes una copia de seguridad.
8. ¿Ayuda actualizar WordPress o los plugins?
Contra PHP2Shell no, porque la vulnerabilidad está en PHP. Las actualizaciones del CMS siguen siendo útiles, porque cierran otras vulnerabilidades.
Comprobar y acreditar
9. ¿Cómo consigo un justificante del proveedor?
Con una solicitud escrita que pida datos concretos: nivel de paquetes por rama de PHP, fecha de la instalación, reinicio de todos los procesos de PHP. Una plantilla para copiar la ofrece la guía Solicitar al proveedor la confirmación de la actualización de PHP.
10. ¿Puedo aplicar medidas provisionales mediante .user.ini?
No. php.net desaconseja expresamente aplicar los ajustes provisionales mediante ini_set() o .user.ini. Corresponden a la configuración del servidor, y en el alojamiento compartido la gestiona el proveedor.
11. Mi sitio web estuvo un rato fuera de línea. ¿Me han hackeado?
No necesariamente. Algunos proveedores desconectaron sitios web o reiniciaron servidores como medida preventiva. Pregunte por el motivo antes de sacar conclusiones.
12. ¿Cómo reconozco que mi sitio web ha sido atacado?
Posibles indicios son cuentas de administrador desconocidas, archivos PHP nuevos en la carpeta de subidas, redirecciones a páginas ajenas, páginas ajenas en el índice de Google o avisos en la Search Console. Pida al proveedor que conserve los registros de acceso desde el 20 de octubre.
Si algo no cuadra
13. El proveedor no responde o responde con evasivas. ¿Qué hago?
Pregunte por escrito y fije un plazo razonable. Si no hay respuesta, debería tratar el servidor como no revisado y plantearse cambiar temporalmente el sitio web a una página de emergencia estática.
14. ¿Debo cambiar de proveedor?
Un cambio en plena situación crea sus propios riesgos. Tiene sentido si el proveedor no da información de forma permanente o sigue operando versiones antiguas de PHP sin corrección. Qué hay que tener en cuenta lo describe Cambiar de proveedor tras un incidente.
15. ¿Tengo que notificar algo?
Si hay indicios de un ataque y pueden estar afectados datos personales, puede existir una obligación de notificación según el RGPD, por lo general en un plazo de 72 horas. Aclárelo con su delegado de protección de datos o con un abogado. Esto no es asesoramiento jurídico.
Su lista de comprobación breve
- Preguntar por escrito al proveedor por el nivel de parcheo y el reinicio.
- Revisar la versión de PHP en el menú de cliente y sustituir las ramas obsoletas.
- Repasar las cuentas de administrador y la carpeta de subidas.
- Revisar en la Search Console si hay avisos.
- Si hay anomalías, buscar ayuda antes de borrar archivos.
¿Cómo ayuda PHP SOS en concreto?
- Aclaración con el proveedor: redactamos la solicitud o mantenemos la conversación y valoramos la respuesta.
- Revisión del sitio web: buscamos indicios en archivos, base de datos y cuentas, en la medida en que lo permita el paquete de alojamiento.
- Limpieza: si encontramos código malicioso, lo eliminamos y cambiamos todos los accesos.
- Documentación: usted recibe el estado por escrito.
Ante una sospecha concreta ayuda la ayuda de emergencia para sitios web hackeados.
Conclusión
Como cliente de alojamiento, con PHP2Shell usted no carga con el peso de la actualización, pero sí con la responsabilidad de su sitio web. La mayoría de las preguntas se resuelven con una respuesta escrita clara de su proveedor. Lo que queda después es mirar su propio sitio web: cuentas, archivos, avisos de Google. Quien ha hecho ambas cosas ha cumplido su parte y puede demostrar, en caso de duda, que actuó con diligencia.
Preguntas frecuentes
¿Quién es responsable de la actualización de PHP en el alojamiento web?
En el alojamiento compartido, por lo general el proveedor, porque es él quien opera el servidor y la instalación de PHP. Usted es responsable de su sitio web, de sus accesos y de elegir la versión de PHP en el menú de cliente. En los servidores gestionados, el contrato regula el reparto.
¿Por qué mi proveedor muestra una versión antigua de PHP?
Muchos proveedores y distribuciones incorporan la corrección como backport en la versión existente. El número se mantiene igual aunque la vulnerabilidad esté cerrada. Por eso fíese de una confirmación escrita del proveedor, no de lo que se muestra.
¿Qué puedo comprobar yo mismo como cliente de hosting?
Puede comprobar la versión de PHP configurada en el menú de cliente, revisar las cuentas de administrador de su CMS, buscar archivos desconocidos en la carpeta de subidas y revisar en la Search Console si hay avisos. El nivel de parcheo del propio servidor solo puede acreditarlo el proveedor.
¿Ayuda un ajuste de cortafuegos en el paquete de alojamiento?
Las reglas de cortafuegos del proveedor o de un servicio previo pueden reducir el riesgo. Pero no sustituyen la actualización de PHP en el servidor. Por eso pregunte siempre primero por la actualización.