Vulnerabilidades en WordPress: qué hacer tras la 7.1.4

El 28 de octubre WordPress publicó la versión 7.1.4 y pidió actualizar de inmediato. Corrige 22 fallos, y un día después Wordfence ya avisaba de intentos de ataque. Si tienes una web o una tienda con WordPress, este artículo es para ti: te explico qué vulnerabilidades de WordPress se han corregido, qué riesgo real suponen y qué hacer hoy.

No hace falta entrar en pánico. Tampoco conviene dejarlo para la semana que viene.

En resumen: WordPress 7.1.4 corrige 22 vulnerabilidades. La más seria permite ejecutar código en el servidor durante los segundos que dura una actualización, sin necesidad de tener cuenta. Es difícil de aprovechar, pero Wordfence dice haber bloqueado casi 63.000 intentos en 24 horas. No hay webs comprometidas confirmadas en las fuentes que he consultado. Comprueba tu versión, actualiza con copia de seguridad y bloquea el acceso público a la carpeta wp-content/upgrade.

¿Qué ha pasado exactamente?

WordPress ha publicado cuatro actualizaciones de seguridad en seis semanas:

17 de septiembre, versión 7.1.1: 11 correcciones de seguridad.
22 de septiembre, versión 7.1.2: un fallo de gravedad crítica que, en determinadas condiciones del servidor y del tema, podía permitir ejecutar código sin iniciar sesión.
6 de octubre, versión 7.1.3: 7 correcciones de seguridad.
28 de octubre, versión 7.1.4: 22 vulnerabilidades.

En medio, el 21 de octubre, el proyecto PHP (el lenguaje con el que funciona WordPress) sacó una actualización urgente por dos fallos críticos. WordPress también lo avisó en su blog oficial. Es decir, en octubre hubo que revisar dos capas distintas de la misma web.

Infografía: 41 vulnerabilidades corregidas en WordPress en seis semanas, 22 en la versión 7.1.4, y 62.969 ataques bloqueados por Wordfence en 24 horas — Fuentes: WordPress.org y Wordfence (citado por The Hacker News). Son intentos de ataque, no webs comprometidas.

¿Qué fallo es el que preocupa?

Durante una actualización completa, WordPress descomprime los archivos nuevos en una carpeta temporal dentro de wp-content/upgrade. Esa copia incluye el instalador. En muchos servidores esa carpeta se puede abrir desde internet, así que un atacante que llegue en el momento justo podría llegar a ejecutar código en tu servidor.

Dicho de forma sencilla: es como dejar abierta la puerta del almacén unos segundos mientras entra el repartidor. Para colarse hay que estar justo ahí y en ese momento. Por eso los ataques consisten en preguntar por esa dirección una y otra vez, de forma automática, esperando a que coincida.

Conviene dar el dato completo, porque no todas las fuentes lo valoran igual:

Afecta a las versiones de la 4.7 a la 7.1.3.
Wordfence le da una puntuación de 8,1 sobre 10 (alta) y ha visto en sus pruebas que el hueco dura solo segundos.
WordPress lo clasifica como gravedad baja.
Patchstack cree que es poco práctico de aprovechar, pero recuerda que no necesita cuenta ni ninguna acción del usuario.

Y lo más importante: según The Hacker News, Wordfence bloqueó 62.969 ataques dirigidos a este fallo en 24 horas. Son intentos, no webs hackeadas. Ni esa noticia ni las demás fuentes de este artículo informan de compromisos confirmados. Pero sí demuestran que hay gente buscándolo de forma activa.

¿Qué significa esto para una pyme?

Que tu web es un objetivo igual que la de una gran empresa. Estos ataques son automáticos: nadie ha elegido tu negocio, un programa prueba miles de webs hasta que alguna coincide. Si alguien consigue entrar, lo que está en juego son tus formularios de contacto, los pedidos de tu tienda, los datos de tus clientes y tu posición en Google.

Hace unas semanas escribí que la mayoría de los fallos de WordPress están en los plugins, y sigue siendo cierto. Esta vez, en cambio, el fallo está en el propio WordPress. Por eso se habla tanto de él: afecta a casi cualquier instalación, tenga los plugins que tenga.

Los otros 21 fallos de la versión 7.1.4 son menos urgentes para la mayoría. Según Patchstack, casi todos necesitan una cuenta con rol de colaborador o superior. Aun así, es buen momento para revisar quién tiene acceso a tu web.

¿No sabes en qué versión está tu web ni quién la actualiza? La reviso contigo y te digo qué falta. Cuéntame tu proyecto

¿Qué tengo que hacer hoy?

Cinco pasos para proteger una web WordPress tras la versión 7.1.4 — El orden importa: primero la copia.

Comprueba tu versión. Entra en tu escritorio de WordPress y abre Actualizaciones. Si pone 7.1.4, ya la tienes. Las webs con actualizaciones automáticas deberían haberla recibido sin hacer nada, pero compruébalo.
Haz una copia y actualiza. Si estás en una rama antigua, WordPress ha publicado parches propios, como la 7.0.8 o la 6.9.11, hasta la 4.7.39. La versión 4.6 y anteriores ya no reciben parches: ahí hay que migrar.
Bloquea el acceso público a wp-content/upgrade. Se hace en la configuración del servidor o en el archivo .htaccess de la raíz, no dentro de esa carpeta. Patchstack insiste en esto porque el hueco se reabre en cada actualización, también en las automáticas. Si no sabes hacerlo, pídeselo a tu hosting o a quien lleve tu web.
Revisa PHP. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Puedes ver cuál usas en Herramientas > Salud del sitio > Información > Servidor. En un hosting compartido lo aplica el proveedor, así que pregúntale. Si tu web sigue en una versión sin soporte, te conviene planear el cambio.
Revisa usuarios y archivos. Mira si hay administradores que no conoces, plugins que no instalaste o archivos PHP extraños. Elimina las cuentas que ya no se usen.

Si usas un plugin de seguridad, déjalo activo, pero no te confíes. Según Patchstack, este fallo no se puede bloquear desde dentro de WordPress, porque la petición llega a una copia que no carga tu instalación. El bloqueo tiene que estar en el servidor.

Técnico web revisando una lista de comprobación en su mesa de trabajo — Una revisión de media hora evita la mayoría de los sustos.

Un ejemplo: la tienda que no quiere tocar nada antes de Black Friday

Imagina una tienda con WooCommerce que vende bien en noviembre. El dueño desactivó las actualizaciones automáticas porque una vez se le rompió el carrito, y ahora no quiere tocar nada hasta enero. Es un miedo razonable, y es justo el escenario más peligroso.

Lo sensato no es elegir entre seguridad y ventas. Es hacer una copia, probar la actualización en una copia de la tienda, comprobar un pedido de principio a fin y pasarla a la web real a una hora tranquila. Con eso se hace en una mañana lo que, tras un ataque en plena campaña, puede costar días de ventas.

¿Sirve de algo hacerlo una sola vez?

No. Si algo enseñan estas seis semanas es que el mantenimiento de una web ya no se puede hacer «cuando me acuerde». Cuatro actualizaciones de seguridad y un parche de PHP en poco más de un mes son demasiadas para llevarlas de memoria.

Lo mínimo que debería tener cualquier web de negocio:

Copias de seguridad automáticas guardadas fuera del servidor.
Alguien pendiente de los avisos de seguridad, no solo de la casilla de actualizar.
Una forma de probar los cambios antes de aplicarlos.
Una lista corta de quién tiene acceso a la web.

Es lo que hago en mi servicio de mantenimiento web. Si prefieres llevarlo tú, en mi artículo sobre actualizar WordPress 7 tienes más contexto, y si estás comparando costes, en cuánto cuesta una página web te cuento qué gastos se repiten cada año.

Preguntas frecuentes

¿Cómo sé si han entrado en mi web?

Busca administradores desconocidos, plugins que no instalaste, archivos PHP extraños o redirecciones a otras webs. Tu hosting también puede revisar si hubo peticiones a archivos dentro de wp-content/upgrade. Si tienes dudas, trátalo como un incidente y pide ayuda antes de borrar nada.

¿Tengo web con WordPress.com, también me afecta?

Si usas un servicio gestionado, normalmente el proveedor se encarga de las actualizaciones. Compruébalo en su panel o pregúntale. Lo que digo aquí pensando en el acceso al servidor sirve sobre todo para webs con hosting propio.

¿La actualización puede romper mi web?

Es una actualización menor de seguridad, así que el riesgo es bajo, pero nunca es cero. Por eso primero se hace la copia.

¿Afecta a Shopify o Wix?

No. Esta vulnerabilidad es del núcleo de WordPress. Otra cosa es que esas plataformas se encarguen ellas de la seguridad a cambio de darte menos control sobre tu web.

¿Las actualizaciones automáticas bastan?

Ayudan mucho, pero no cubren todo: no tocan el PHP de tu servidor, y no te avisan si algo falla. Mantén la opción activada, y revisa de vez en cuando que funciona.

¿Quieres quitarte este tema de encima? Reviso tu web y te dejo claro qué hay que hacer. Hablemos.

Fuentes

Christian Arroyo

Diseñador web freelance en Castellón, especializado en WordPress, Elementor y SEO.

Etiquetas: Mantenimiento, Seguridad, WordPress