Vulnerabilidad en WordPress: qué es, a quién afecta y cómo proteger tu sitio hoy

El 28 de octubre de 2026 WordPress publicó la versión 7.1.4 para cerrar una vulnerabilidad que permite ejecutar código en un servidor sin necesidad de tener una cuenta. Dos días después, según The Hacker News, la firma de seguridad Wordfence reportó que había bloqueado 62.969 intentos de explotarla en solo 24 horas.

Si tu negocio depende de un sitio en WordPress, esto te toca de forma directa. La falla no está en un plugin dudoso ni en un tema pirata: está en el núcleo, en el mecanismo que usas para protegerte, la actualización. En esta guía te explicamos qué pasó, qué significa el CVSS 8,1 que acompaña a la noticia, a quién afecta y qué hacer hoy mismo. Lo escribimos desde Gulupa Digital, la agencia de Medellín que crea y da soporte a sitios WordPress para empresas desde 2016.

Qué pasó: fechas, versiones y cifras

Estos son los datos que confirman las fuentes:

• Fecha del parche: 28 de octubre de 2026, con WordPress 7.1.4.
• Alcance de la versión: WordPress cuenta 22 vulnerabilidades corregidas, repartidas en 17 avisos, según Patchstack.
• La más grave: una condición de carrera durante las actualizaciones del núcleo que puede terminar en ejecución remota de código (RCE). La reportó el investigador Umut Bayram.
• Versiones afectadas: del núcleo de WordPress 4.7 a la 7.1.3.
• Puntaje: CVSS 8,1, nivel alto. Al cierre de la noticia no tiene identificador CVE.
• Ataques: Wordfence bloqueó 62.969 intentos en 24 horas.

Las demás vulnerabilidades de la versión son menos urgentes: casi todas exigen al menos una cuenta de colaborador, según Patchstack. Por eso toda la atención se concentró en la falla de la actualización, la que más preocupa porque no exige cuenta.

Cómo funciona la falla, en palabras simples

Imagina que remodelas tu oficina. Los obreros descargan los materiales en el pasillo, con la puerta de la calle abierta, y tardan unos minutos en terminar. Si alguien entra justo en ese momento, puede tocar lo que aún no está asegurado.

Algo parecido ocurre con WordPress. Cuando aplica una actualización completa del núcleo, descomprime los archivos nuevos en una carpeta temporal llamada wp-content/upgrade. Esa copia incluye el instalador de WordPress. En muchos servidores esa carpeta se puede abrir desde el navegador y su ruta es predecible. Un atacante que pida el instalador en el instante exacto puede interactuar con esa copia a medio instalar y llegar a ejecutar código PHP en tu servidor. Es lo que en seguridad se llama una condición de carrera: gana quien llega en el momento justo.

Para que el ataque funcione deben coincidir cuatro cosas:

• Una actualización completa que contenga los archivos del instalador.
• Acceso web y PHP público a esa carpeta temporal.
• Una ruta predecible o descubierta.
• Tiempo suficiente antes de que WordPress borre los archivos temporales.

En laboratorio esa ventana dura segundos, y Wordfence advierte que el atacante debe acertar en ella. Ejecutar código en tu servidor significa, en la práctica, poder crear administradores, instalar archivos maliciosos o modificar tu sitio.

Qué es el CVSS y por qué esta falla tiene 8,1

CVSS son las siglas de Common Vulnerability Scoring System, en español, Sistema de Puntuación de Vulnerabilidades Comunes. Es un estándar abierto que mantiene FIRST y que la base de datos oficial de vulnerabilidades de Estados Unidos, la NVD, usa para calificar casi todas las fallas conocidas. Resume en un número de 0 a 10 qué tan grave es una vulnerabilidad desde el punto de vista técnico.

La escala de la versión 3 se lee así:

• 0,1 a 3,9: baja.
• 4,0 a 6,9: media.
• 7,0 a 8,9: alta.
• 9,0 a 10: crítica.

La falla de WordPress tiene 8,1, es decir, alta y a menos de un punto de crítica. Una lectura nuestra, que ninguna de las fuentes confirma: es probable que no llegue a 9 porque el ataque exige acertar en una ventana de segundos. Eso no la hace inofensiva, y hay dos razones.

La primera es que el CVSS mide la gravedad técnica de la falla, no si alguien la está explotando hoy. Aquí sí hay explotación: Wordfence observó atacantes sondeando sitios durante horas para pillar ese instante. La segunda es que no se necesita cuenta. Cualquier visitante anónimo puede intentarlo.

A quién afecta y qué versión instalar

Afecta al núcleo de WordPress desde la versión 4.7 hasta la 7.1.3, o sea, a casi cualquier sitio que no se haya actualizado esta semana. No depende de tus plugins ni de tu tema, aunque un hosting que deja wp-content/upgrade abierto a la web sí aumenta la exposición.

Qué versión instalar depende de tu rama:

• Si estás en la rama 7.1: actualiza a la 7.1.4.
• Si estás en una rama anterior con soporte: instala la última versión de esa rama. WordPress publicó correcciones para todas las ramas soportadas, hasta la 4.7.39, según Patchstack.
• Si estás en la 4.6 o anterior: esas versiones ya no reciben parches de seguridad, según la página oficial de la versión 7.1.4. Aquí el problema es más grande que esta falla y toca migrar.

Algunos proveedores de hosting administrado, como Pantheon, anunciaron mitigaciones a nivel de plataforma. Aun así, pidieron a sus clientes actualizar cuanto antes. Si tu sitio está en un hosting así, pregunta qué reglas aplicaron, pero no lo tomes como sustituto del parche.

Qué dicen de verdad los 62.969 intentos

La cifra es de Wordfence y cuenta ataques bloqueados por su firewall en los sitios que protege. No son sitios comprometidos, y los reportes disponibles no dicen cuántos sitios sin protección fueron vulnerados. Leerla como «62.969 sitios hackeados» es un error.

Lo que sí muestra el dato es el comportamiento de los atacantes. Dos de las mayores fuentes sondearon pequeños grupos de sitios durante unas 14,5 horas seguidas, algo coherente con esperar la breve ventana de una actualización. Otras probaron muchas variaciones de nombres de carpeta y de versión, y varias consultaron una y otra vez archivos como setup-config.php. Alex Thomas, quien lidera el equipo de respuesta a amenazas de Wordfence, señala que no todas las solicitudes usaron la ruta exacta vulnerable, pero que el sondeo sostenido indica que entendieron la condición de carrera casi de inmediato.

Lo que debes llevarte: pasaron dos días entre el parche y un sondeo masivo y automatizado. Si esperas a la próxima revisión mensual para actualizar, ya perdiste esa carrera.

Qué hacer hoy, paso a paso

1. Haz un respaldo completo de archivos y base de datos. Es tu punto de retorno si algo falla durante la actualización.
2. Cierra el acceso web a wp-content/upgrade antes de actualizar. Según Patchstack, el ataque exige que esa carpeta sea alcanzable por web. Cerrarla es una mitigación que deducimos de esa condición, no una medida oficial de WordPress ni de Wordfence. En Apache, en el .htaccess de la raíz y antes del bloque de WordPress:RewriteEngine On RewriteRule ^wp-content/upgrade/ - [F,L]
   En Nginx, dentro del bloque server del sitio:location ^~ /wp-content/upgrade/ { deny all; }
   Si no administras tu servidor, pídele a tu hosting o a tu equipo técnico que lo aplique. Después confirma que las actualizaciones siguen funcionando.
3. Actualiza el núcleo. 7.1.4 si estás en la rama 7.1, o la última versión de tu rama. Confírmalo en Escritorio > Actualizaciones o con wp core version.
4. Actualiza también plugins y temas. Esta falla es del núcleo, pero la misma ventana de mantenimiento es el momento de cerrar lo que tengas atrasado.
5. Revisa si ya te tocó, como explicamos a continuación.

Cómo saber si ya te afectó

Wordfence recomienda buscar solicitudes sospechosas a archivos PHP dentro de wp-content/upgrade, además de administradores, plugins o archivos PHP que no reconozcas. En la práctica:

• Logs de acceso: busca la cadena wp-content/upgrade (por ejemplo con grep "wp-content/upgrade" access.log). Una respuesta 200 a un archivo PHP en esa ruta merece investigación.
• Administradores: wp user list --role=administrator. Cualquier cuenta que no creaste tú o tu equipo es una alerta.
• Plugins: wp plugin list. Busca plugins que nadie instaló.
• Archivos del núcleo: wp core verify-checksums compara tus archivos con los oficiales.
• Archivos PHP recientes en wp-content que no correspondan a una actualización tuya.

Si encuentras algo, no borres a ciegas. Aísla el sitio, conserva los logs, restaura desde un respaldo limpio anterior al incidente y cambia todas las credenciales: WordPress, base de datos, hosting y las claves de wp-config.php.

Por qué un WordPress sin mantenimiento sale caro

El problema de fondo rara vez es la falla puntual. Es cuánto tardas en enterarte y en parchar. El parche salió el 28 de octubre y en un par de días ya había sondeo automatizado y sostenido contra ella. Un sitio sin responsable, sin respaldos probados y sin reglas en el servidor queda dependiendo de la suerte.

Un WordPress que vende o capta clientes necesita, como mínimo, un proceso que cubra esto:

• Respaldos que se prueban, no solo se programan.
• Actualizaciones controladas, primero en un entorno de pruebas y luego en producción, para no romper el diseño ni el carrito de compras.
• Reglas en el servidor que cierren rutas que nadie debería abrir desde internet.
• Revisión periódica de usuarios administradores, plugins y archivos.
• Alguien que lea los avisos de seguridad el mismo día en que salen, como este.

En Gulupa Digital trabajamos con WordPress, Elementor Pro y WooCommerce, y sabemos que lo que más duele no es la falla, sino enterarse tarde. Si quieres que revisemos la versión, la exposición de carpetas, los usuarios y los archivos de tu sitio, conoce nuestros planes de soporte técnico para WordPress. Si estás pensando en un sitio nuevo, mira cómo hacemos el desarrollo de sitios web en WordPress y cómo se conecta con tu estrategia de SEO. También publicamos avisos como este en nuestro Instagram.

Preguntas frecuentes sobre la vulnerabilidad de WordPress

¿Mi sitio fue hackeado si usa una versión entre la 4.7 y la 7.1.3?

No necesariamente. Tu sitio es vulnerable, pero la explotación exige acertar en la ventana de segundos de una actualización completa del núcleo y que la carpeta wp-content/upgrade sea accesible por web. Aun así, conviene actualizar y revisar tus logs.

¿Qué es una ejecución remota de código (RCE)?

Es una falla que permite a alguien ejecutar sus propias instrucciones en tu servidor desde internet. Con eso puede crear administradores, subir archivos maliciosos o modificar tu sitio.

¿Qué significa que tenga CVSS 8,1?

El CVSS califica de 0 a 10 la gravedad técnica de una vulnerabilidad. De 7,0 a 8,9 se considera alta y de 9,0 a 10 crítica. La falla de WordPress está en alta, a menos de un punto de crítica.

¿Un plugin de seguridad o un firewall me protege?

Puede bloquear intentos, como los 62.969 que reportó Wordfence, pero la solución definitiva es el parche. Úsalo como capa extra, no como sustituto de actualizar.

¿Qué pasa si tengo WordPress 4.6 o una versión más antigua?

Esas versiones ya no reciben actualizaciones de seguridad. Necesitas migrar a una versión con soporte, con respaldo previo y pruebas, porque saltar tantas versiones puede romper plugins y diseño.