Seguridad en WordPress: por qué actualizar no siempre basta

El 6 de octubre WordPress publicó la versión 7.1.3, que corrige siete fallos de seguridad. Es la tercera versión de seguridad en menos de tres semanas: la 7.1.1 salió el 17 de septiembre y la 7.1.2, cinco días después. En esas mismas fechas Patchstack ha documentado una campaña que se cuela por el plugin de formularios Ninja Forms y deja dentro de la web un administrador que no aparece en la lista de usuarios.

No es motivo de alarma, pero sí para dedicarle diez minutos a tu web esta semana. Lo contamos por partes.

Tres versiones de seguridad en tres semanas

• WordPress 7.1.1 (17 de septiembre). Patchstack lo bautizó Click2Shell: con un solo clic, un administrador con la sesión abierta podía dar a un atacante el control del servidor. Hace falta que ese administrador pinche en un enlace preparado (o que la web ya tenga otro fallo que lo provoque), así que el riesgo real es el correo de phishing bien hecho.
• WordPress 7.1.2 (22 de septiembre). Es la grave: CVE-2026-87902, con una nota de 9,2 sobre 10. No hace falta ningún usuario para atacar, y afecta a todas las versiones desde la 4.7, casi diez años de WordPress. Llegar a ejecutar código depende de dos detalles del tema y de la configuración de PHP que se dan en algunos alojamientos compartidos con cPanel. Según Patchstack, los primeros sondeos buscando webs sin parchear llegaron horas después del parche.
• WordPress 7.1.3 (6 de octubre). Siete fallos de seguridad de distinto tipo: código inyectado en la pantalla de comentarios, una inyección SQL en la exportación, comentarios de entradas privadas visibles sin iniciar sesión o autores que podían fijar entradas en portada sin tener permiso para ello.

Las tres llegan solas a las webs que tienen encendidas las actualizaciones automáticas. Las que no las tienen dependen de que alguien las instale a mano: si nadie lo ha hecho, siguen con los fallos abiertos. WordPress está llevando los parches, por cortesía, a las ramas antiguas que aún los reciben (hoy, hasta la 4.7), pero recuerda que solo la versión más reciente tiene soporte activo.

Ninja Forms: actualizar cierra la puerta, pero no echa a quien ya entró

Ninja Forms está instalado en más de 500.000 webs. Hasta la versión 3.15.3 tenía un fallo (CVE-2026-94504) que permitía guardar código en un envío del formulario. El ataque que ha descrito Patchstack, visto por primera vez el 4 de octubre, funciona así:

1. El atacante rellena un formulario de la web con el código escondido en un campo.
2. Un administrador entra en el escritorio a mirar los envíos, como cualquier día.
3. Al abrirlos, el código se ejecuta con la sesión del administrador y, en su nombre, instala un plugin que se presenta como «WP Smart Thumbnails». En realidad es un gestor de ficheros sin contraseña.
4. Además crea un administrador nuevo con un nombre que no llama la atención («support», «updater»…) y dos ficheros en wp-content/mu-plugins que lo esconden de la lista de usuarios y abren un acceso con enlace mágico.

La misma campaña usa un fallo parecido en WPC Product Bundles for WooCommerce (hasta la 8.6.6). Patchstack dice que de momento el volumen es limitado, pero la técnica es lo que preocupa. Actualizar a Ninja Forms 3.15.4 cierra el fallo, pero no borra nada de lo que el ataque ya haya dejado. Y los ficheros nuevos llevan fechas falsas para pasar por antiguos.

Qué revisar en tu web esta semana

• La versión de WordPress. En Escritorio → Actualizaciones tiene que poner 7.1.3, o la última de tu rama si usas una antigua.
• Que las actualizaciones automáticas estén encendidas para las versiones de seguridad. Así los parches llegan el mismo día, sin depender de que alguien se acuerde.
• Ninja Forms y WPC Product Bundles, si los usas: 3.15.4 y 8.6.7 o posteriores.
• Los plugins instalados. Si aparece uno que nadie recuerda haber instalado, y en especial «WP Smart Thumbnails», es un indicio de que la web puede estar comprometida, y hay que revisarla.
• La carpeta wp-content/mu-plugins. En muchas webs ni existe, y en otras guarda componentes legítimos del alojamiento o de algún plugin, así que no se borra nada a ciegas. Si tiene ficheros como class-wp-query- seguido de letras y números, o class-wp-token-validate.php, hay que investigarlos.
• Los administradores reales. El usuario oculto no sale en la pantalla de Usuarios. Para verlo hay que consultar la base de datos o pedírselo a quien te lleve el alojamiento. Comparar esa lista con las personas que de verdad deberían tener acceso es el paso que más se salta.

Si algo de esto aparece, no basta con borrar el plugin: hay que cambiar contraseñas, revisar ficheros y base de datos y, a ser posible, partir de una copia anterior al ataque.

Lo que hacemos nosotros

Septiembre ha sido un buen ejemplo de por qué el mantenimiento de WordPress no se puede dejar para cuando haya tiempo. Hemos tenido tres versiones de seguridad seguidas, una de ellas explotable sin usuario, y un ataque que no deja rastro en la pantalla de usuarios. Un mantenimiento que merezca el nombre aplica las versiones de seguridad en cuanto salen, revisa los plugins contra los avisos de Wordfence y Patchstack, y repasa la lista de administradores en la base de datos, no solo en el escritorio.

Si tu web en WordPress no tiene a nadie detrás, cuéntanoslo en soporte técnico de WordPress. Si solo quieres un primer vistazo desde fuera, nuestro comprobador de seguridad web es gratuito. Y si te interesa cómo lo enfocamos, en Seguridad WP contamos cómo trabajamos la seguridad, el mantenimiento y el soporte de WordPress.