Esta semana hemos vivido uno de esos momentos que nos recuerdan que la seguridad de una página web no consiste únicamente en tener WordPress y sus plugins actualizados.
Durante los últimos días junto con mi equipo en invertiaWeb, hemos tenido que revisar configuraciones, versiones de PHP, plugins, usuarios y accesos de diferentes sitios web. Y lo más importante es que hemos tenido dos incidentes de seguridad diferentes que han coincidido en el tiempo y que conviene no confundir.
Mi objetivo con este artículo es explicar qué ha ocurrido y, sobre todo, qué podemos hacer si trabajamos con una página web.
1. El incidente de UpdraftPlus: cuando una actualización no es suficiente
El primer caso está relacionado con TeamUpdraft, responsable de UpdraftPlus, uno de los plugins de copias de seguridad más utilizados en WordPress.
TeamUpdraft informó de un acceso no autorizado a sus sistemas durante el fin de semana del 17 y 18 de octubre. Entre la información potencialmente afectada estaban las claves de conexión utilizadas por UpdraftCentral. Estas conexiones permiten gestionar sitios WordPress de forma remota.
El problema es especialmente importante porque el atacante pudo utilizar ese acceso para actuar sobre sitios conectados: crear usuarios, instalar plugins maliciosos y dejar mecanismos de acceso que posteriormente podrían utilizarse para mantener el control.
Por eso, en este caso actualizar el plugin no debía ser el único paso.
TeamUpdraft publicó las versiones 1.26.13 y 2.26.13 de UpdraftPlus, que revocaban las claves de conexión de UpdraftCentral y bloqueaban ese vector de acceso. Sin embargo, también recomendó revisar los sitios para detectar usuarios, plugins o actividad inesperada.
¿Qué hice y qué recomiendo?
Ante una situación como esta, mi procedimiento es:
- Revisar los plugins instalados.
- Comprobar que UpdraftPlus está actualizado.
- Revisar los usuarios administradores y detectar cuentas que no reconozcamos.
- Revisar las conexiones de UpdraftCentral.
- Revocar credenciales y claves antiguas cuando sea necesario.
- Cambiar las contraseñas de los administradores.
- Revisar la actividad de la web después de la actualización.
Los años te enseñan: si un atacante ya ha conseguido entrar, actualizar el software no significa necesariamente que el problema haya desaparecido.
2. Dos vulnerabilidades críticas en PHP
El segundo incidente afecta directamente a PHP, una tecnología fundamental para millones de páginas web y, especialmente, para WordPress.
El 21 de octubre de 2026, el equipo de PHP publicó actualizaciones de seguridad para corregir las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, clasificadas con una gravedad CVSS 4.0 de 9,2.
El problema es especialmente serio porque pueden permitir ejecución remota de código sin autenticación. PHP indica además que no existen mitigaciones completas y que actualizar es la única solución segura. Las versiones 8.2, 8.3, 8.4 y 8.5 recibieron actualizaciones de seguridad para corregir estas vulnerabilidades.
En otras palabras: no estamos hablando únicamente de un problema de WordPress o de un plugin. El propio lenguaje de programación que utiliza el servidor necesitaba ser actualizado.
En algunos servidores también se ha aplicado como medida preventiva adicional la desactivación del seguimiento de las subidas de archivos:
session.upload_progress.enabled = Off
La propia documentación de PHP explica que esta funcionalidad escribe determinados datos relacionados con las subidas en la sesión y que, en aplicaciones que no utilizan barras de progreso para las subidas, se puede desactivar.
Y desde el 23 de octubre apareció una tercera vulnerabilidad de PHP, CVE-2026-115560, para la que PHP recomienda precisamente desactivar session.upload_progress.enabled como mitigación temporal en determinadas configuraciones. Por tanto, ahora tenemos que distinguir entre las dos vulnerabilidades originales, que requieren actualizar PHP, y esta tercera, donde esa configuración tiene un papel específico.
Pero quiero insistir en algo importante: esta configuración no sustituye a la actualización de PHP.
¿Cómo puedo saber qué versión de PHP utiliza mi WordPress?
Esta es una de las comprobaciones que recomiendo hacer a cualquier emprendedor que tenga una web WordPress.
No necesitamos acceso SSH ni conocimientos avanzados de servidores.
Desde el propio WordPress podemos entrar en:
Herramientas ? Salud del sitio ? Información ? Servidor
Allí encontraremos el apartado Versión de PHP.
Esta información es especialmente útil porque nos indica la versión de PHP que está utilizando realmente WordPress. No debemos confundirla necesariamente con la versión que podamos obtener mediante un comando de terminal del servidor.
PHP 8.2: el 31 de diciembre es una fecha importante
Hay otro motivo para actuar ahora y no esperar a final de año.
PHP 8.2 llegará al final de su vida útil el 31 de diciembre de 2026. A partir de esa fecha dejará de recibir actualizaciones de seguridad oficiales. PHP 8.3 tendrá soporte de seguridad hasta finales de 2027, mientras que PHP 8.4 tendrá soporte de seguridad hasta finales de 2028.
Además, WordPress recomienda actualmente utilizar PHP 8.3 o superior.
Por eso, si gestiono una web que todavía funciona con PHP 8.2, no esperaría a diciembre.
Mi recomendación práctica es:
PHP 8.3: una opción muy equilibrada para WordPress, especialmente cuando buscamos estabilidad y compatibilidad.
PHP 8.4: una alternativa muy interesante cuando el hosting, el tema y los plugins han sido comprobados y son compatibles.
La decisión no debería consistir simplemente en seleccionar una versión nueva y pulsar un botón. Antes de hacerlo debemos disponer de una copia de seguridad y comprobar la compatibilidad de los plugins y del tema, especialmente si tenemos una tienda online, formularios, reservas o cualquier funcionalidad crítica.
Mi recomendación para los próximos meses
Después de lo ocurrido esta semana, yo no esperaría a que aparezca el próximo aviso de seguridad para revisar una web.
Antes de terminar 2026 recomiendo que compruebes estos cinco puntos:
1. WordPress y plugins actualizados.
Especialmente aquellos relacionados con copias de seguridad, administración remota y acceso.
2. Usuarios y administradores.
Eliminar cuentas que no reconozcamos y revisar permisos innecesarios.
3. Versión de PHP.
Comprobarla desde Salud del sitio y planificar la actualización si utilizamos PHP 8.2, a una superior
4. Copias de seguridad.
No basta con hacer copias: debemos saber dónde están almacenadas y comprobar periódicamente que podemos recuperarlas.
5. Revisión después de una incidencia.
Cuando existe una vulnerabilidad que puede haber permitido acceso al servidor o a WordPress, debemos comprobar que no hayan quedado usuarios, plugins, archivos o accesos no autorizados.
¿Y qué ocurre con nuestra Oficina Virtual basada en Odoo?
Una pregunta que me han planteado estos días es si este incidente también afecta a nuestra Oficina Virtual para emprendedores y pequeñas empresas basada en Odoo.
La respuesta, con la información disponible actualmente, es no.
Odoo no utiliza PHP como lenguaje principal de su plataforma. Su aplicación está desarrollada principalmente en Python y utiliza PostgreSQL como base de datos. Por tanto, las vulnerabilidades críticas de PHP que hemos explicado en este artículo no afectan directamente al núcleo de Odoo. Además, Odoo mantiene actualmente Odoo 18 y Odoo 19 entre sus versiones soportadas.
Esto no significa que una infraestructura tecnológica pueda quedar fuera de un programa de mantenimiento y seguridad. En nuestro caso, revisamos también los componentes del servidor, las aplicaciones expuestas a Internet, las actualizaciones y las configuraciones de seguridad.
Es importante diferenciar una cosa de otra: una vulnerabilidad de PHP no convierte automáticamente en vulnerable cualquier aplicación que esté alojada en un servidor Linux. El riesgo depende de qué software esté instalado, qué servicios estén expuestos y qué versiones se estén ejecutando.
Por eso, cuando aparece una alerta de este nivel, nuestra recomendación es revisar la infraestructura completa y no limitarse únicamente a la aplicación que conocemos.
¿Necesitas ayuda para revisar tu página web?
Si después de leer este artículo no sabes qué versión de PHP está utilizando tu WordPress, tienes dudas sobre una actualización, has detectado algún comportamiento extraño o simplemente quieres comprobar que tu web está correctamente protegida, puedes contactar con nosotros.
No es necesario esperar a tener un problema para revisar la seguridad de una página web.
Si nos contactas haciendo referencia a este artículo sobre las vulnerabilidades de PHP y WordPress, podemos agendar una primera reunión de revisión y orientación sin ningún coste y sin compromiso.
Nuestro objetivo es ayudarte a entender qué tienes instalado, qué debes actualizar y qué actuaciones conviene priorizar, especialmente si tu web es una herramienta importante para tu negocio.
La seguridad empieza por saber qué tenemos y mantenerlo actualizado.
Y, como siempre digo, no se trata de alarmarse cada vez que aparece una alerta de seguridad, sino de tener un sistema de mantenimiento que nos permita reaccionar rápidamente cuando sucede.
Una última reflexión
Para una pequeña empresa, una página web puede parecer simplemente una herramienta comercial: nuestra tarjeta de presentación, nuestro catálogo o nuestro canal de ventas.
Pero detrás hay un servidor, PHP, una base de datos, WordPress, plugins, usuarios, contraseñas, copias de seguridad, APIs y diferentes sistemas conectados.
Por eso, la seguridad de una web no es una actuación puntual: es mantenimiento.
Lo ocurrido esta semana con UpdraftPlus y PHP nos recuerda precisamente eso. No necesitamos convertirnos en expertos en ciberseguridad, pero sí debemos asegurarnos de que alguien revise periódicamente aquello que nosotros no podemos controlar.
Y si tenemos una web empresarial que todavía funciona con PHP 8.2, octubre y noviembre son un buen momento para planificar la actualización, probarla y llegar a 2027 con los deberes hechos.