En resumen: Una actualización de WordPress no ayuda contra la vulnerabilidad de PHP PHP2Shell, porque el fallo no está en WordPress, sino en PHP, el software del servidor que ejecuta WordPress. Según Dr. Web, WordPress.org por eso tampoco prevé una actualización propia. Solo puede proteger una actualización de PHP en el servidor con el reinicio de todos los procesos de PHP. Eso lo aplica por lo general su proveedor de alojamiento o el administrador del servidor.
El punto de partida: «Si lo hemos actualizado todo»
Tras los primeros titulares sobre PHP2Shell, muchos administradores hicieron lo más evidente: abrir el escritorio de WordPress, hacer clic en «Actualizar ahora» y actualizar también plugins y temas. Después todo está en verde y la sensación dice: hecho.
Con esta vulnerabilidad la sensación engaña. No se debe a WordPress, sino a dónde está el fallo. También Cloudflare señala en su aviso que una actualización del código de la aplicación o de los plugins no corrige las vulnerabilidades.
Actualización de WordPress y vulnerabilidad de PHP: el modelo de capas
Un sitio web WordPress consta de varias capas que se apoyan unas en otras. Cada capa tiene sus propias actualizaciones y, con frecuencia, sus propios responsables:
| Capa | Ejemplo | Quién actualiza normalmente | ¿Afectada por PHP2Shell? |
|---|---|---|---|
| Sistema operativo | Debian, Ubuntu, AlmaLinux | proveedor de alojamiento o administrador del servidor | no, pero suele suministrar el paquete de PHP |
| Servidor web | Apache, Nginx, LiteSpeed | proveedor de alojamiento o administrador del servidor | el modo de ejecución influye en el riesgo |
| Entorno de ejecución de PHP | PHP-FPM, mod_php | proveedor de alojamiento o administrador del servidor | sí, aquí está la vulnerabilidad |
| Núcleo de WordPress | WordPress | administrador o agencia | no |
| Plugins y temas | WooCommerce, Page-Builder | administrador o agencia | no |
El botón de actualización del escritorio solo alcanza las dos filas inferiores. El entorno de ejecución de PHP está por debajo y es invisible para WordPress. Cómo se apoyan otros sistemas en PHP lo describe el artículo CMS y tiendas sobre PHP.
Por qué WordPress no puede cerrar la vulnerabilidad
Se podría pensar que WordPress podría «programar alrededor». En PHP2Shell eso no funciona por dos motivos.
Primero, ambos fallos están en la forma en que PHP procesa las peticiones y después limpia. Eso ocurre con independencia de qué programa se ejecute en PHP. Segundo, el equipo de PHP demostró para Apache con mod_php un exploit que actúa antes de que se ejecute siquiera el código de la aplicación. WordPress, sus plugins y cualquier plugin de seguridad ni siquiera llegan a intervenir.
Por la misma razón tampoco ayuda ningún «plugin de refuerzo» que cambie ajustes mediante ini_set(). php.net desaconseja expresamente aplicar las medidas provisionales por esa vía.
¿Y con WordPress gestionado?
En las ofertas de WordPress gestionado, el proveedor suele ocuparse no solo de las actualizaciones de WordPress, sino también del servidor que hay debajo. Para PHP2Shell eso es una ventaja, pero no un automatismo. Pregunte de forma concreta si se ha aplicado la actualización de PHP y se han reiniciado todos los procesos de PHP. La afirmación «Mantenemos su WordPress al día» no responde a esa pregunta.
Muchos sitios web, una instalación de PHP
Las agencias y las empresas con varios sitios web deberían conocer una particularidad: en un servidor, muchas instalaciones de WordPress suelen compartir la misma versión de PHP. Si esta no está parcheada, todas están afectadas, con independencia de lo bien mantenido que esté cada sitio web. Y al revés, una actualización de PHP protege todas las instalaciones a la vez, siempre que después se reinicien todos los procesos de PHP correspondientes. Quien opere varias versiones de PHP en paralelo debe actualizar cada una por separado.
Un escritorio de WordPress en verde no dice nada sobre PHP2Shell. Lo decisivo es el nivel de parcheo de PHP en el servidor y el reinicio de todos los procesos de PHP.
Leer correctamente la versión de PHP en WordPress
WordPress muestra la versión de PHP: en el escritorio, en Herramientas, Salud del sitio, en el apartado de información, en la sección Servidor. Es un buen primer indicio, pero no una prueba.
Si aparece una rama como 8.1 o anterior, es una señal de advertencia clara, porque ya no hay actualizaciones oficiales para ella. Si aparece 8.2.35, 8.3.36, 8.4.27 u 8.5.12, está instalada la versión corregida. Si aparece un número más antiguo de una rama compatible, puede haberse aplicado igualmente un backport. Las distribuciones y los proveedores de alojamiento suelen no cambiar el número en ese caso. Solo aclaran la duda la confirmación del proveedor o un vistazo al registro de cambios del paquete. Cómo hacerlo figura en Comprobar la versión de PHP y el nivel de parcheo.
Qué deberían hacer en su lugar los administradores de WordPress
- Preguntar al proveedor de alojamiento o al administrador del servidor: ¿está PHP parcheado, cuándo, y se han reiniciado todos los procesos de PHP? Respuesta por escrito.
- Revisar la rama de PHP: si el sitio web funciona en 8.1 o anterior, planificar el cambio a una rama compatible. Qué versión admite su versión de WordPress figura en los requisitos del sistema en wordpress.org. El cambio en el menú de cliente lo describe Cambiar la versión de PHP en el área de cliente del alojamiento.
- Buscar indicios: archivos PHP nuevos en
wp-content/uploads, cuentas de administrador desconocidas, entradas ajenas enmu-plugins. Los escondites típicos los describe la página WordPress y PHP2Shell. - Mantener WordPress al día de todos modos: el núcleo, los plugins y los temas cierran otras vulnerabilidades. Sigue siendo una obligación, solo que otra.
- Aclarar la responsabilidad: si una agencia atiende el sitio web, dejar constancia de si también es responsable de PHP o solo de WordPress.
Justo el último punto genera con frecuencia lagunas. La agencia mantiene WordPress, el proveedor el servidor, y cada uno cree que el otro tiene PHP2Shell controlado.
¿Cómo ayuda PHP SOS en concreto?
- Aclarar las capas: determinamos quién es responsable de cada capa en su sitio web WordPress.
- Actualizar PHP: en servidores propios o gestionados aplicamos la actualización de PHP y reiniciamos todos los procesos.
- Revisar WordPress: buscamos indicios de un ataque en archivos, base de datos y cuentas.
- Justificante: usted recibe el nivel de parcheo por escrito, también para entregarlo a la agencia o a los clientes.
El procedimiento lo describe el servicio de parcheo de PHP.
Conclusión
La actualización de WordPress es un buen mantenimiento, pero contra PHP2Shell es la capa equivocada. La vulnerabilidad está un piso más abajo, en PHP en el servidor. Quien lo entiende hace la pregunta correcta a la instancia correcta: ¿está PHP parcheado, reiniciado y acreditado?
Preguntas frecuentes
¿Publica WordPress una actualización de seguridad contra PHP2Shell?
Según Dr. Web, WordPress.org no prevé ninguna actualización contra PHP2Shell, porque la vulnerabilidad está en el intérprete de PHP del servidor. Solo ayuda una actualización de PHP por parte del proveedor de alojamiento o del administrador del servidor.
¿Dónde veo la versión de PHP en WordPress?
En el escritorio, en Herramientas, Salud del sitio, en el apartado de información, en la sección Servidor. Pero el número mostrado no dice con certeza si el parche está aplicado, porque los proveedores suelen incorporar las correcciones como backport sin un nuevo número de versión.
¿Protege un plugin de seguridad contra PHP2Shell?
Solo de forma muy limitada. Un plugin funciona él mismo en PHP y solo se activa cuando WordPress está cargado. En Apache con mod_php, según el equipo de PHP, se demostró un exploit antes de que se ejecute siquiera el código de la aplicación. Ahí un plugin no puede intervenir.
¿Debo actualizar WordPress de todos modos?
Sí. Las versiones actuales de WordPress, de los temas y de los plugins cierran otras vulnerabilidades y forman parte de un buen mantenimiento. Lo único que no resuelven es el problema PHP2Shell.