El 17 de julio de 2026, WordPress sacó la versión 7.0.2 para cerrar un fallo crítico en el propio núcleo. Según Patchstack, los primeros intentos de ataque llegaron a sus sensores unos 90 minutos después de publicarse esa versión. No días. Minutos.
Ese dato cambia la pregunta que conviene hacerse. Ya no es «¿cuánta puntuación tiene este fallo?», sino «¿cuánto tardo yo en actualizar?». Este artículo repasa lo que de verdad se ha atacado este año (hasta el 25 de octubre), lo que enseña cada caso y una rutina de actualizaciones que una web de empresa o una tienda puede cumplir sin volverse loca.
Lo que se ha atacado, caso a caso
Caso | Puntuación | Corregido en | Qué se sabe del ataque |
|---|---|---|---|
WordPress (wp2shell): CVE-2026-63030 + CVE-2026-60137 | 9,8 y 5,9 según el NVD | 7.0.2, 6.9.5 y 6.8.6 (17-7-2026) | Ataques unos 90 min tras la versión. En el catálogo KEV de la CISA el 21-7 |
WordPress: CVE-2026-87902 | 9,2 (Patchstack) | 7.1.2 y ramas anteriores (22-9-2026) | Primer intento el mismo día, 11:49 UTC. En KEV el 25-9 |
Elementor Pro: CVE-2026-32475 | 9,0 | 4.2.2 (19-8-2026) | Ver más abajo |
Bricksforge: CVE-2026-85097 | 10,0 (Patchstack) / 9,8 (NVD) | 3.1.8.10 | Ataques desde el 7-10-2026, antes del aviso público |
All-in-One WP Migration: CVE-2026-19949 | 8,8 | 7.110 | Explotación sin confirmar |
Everest Forms Pro: CVE-2026-3300 | 9,8 | Afecta hasta la 1.9.12 | Descrito como explotado; no confirmado en fuente primaria |
KEV es el catálogo de vulnerabilidades explotadas que mantiene la agencia de ciberseguridad de EE. UU. (CISA). Que algo entre ahí significa que hay evidencia de uso real. Sus cifras salen de su archivo público, consultado el 23 de octubre.
wp2shell: dos fallos que juntos eran una puerta abierta
Es el caso más serio del año, porque afectó al núcleo de WordPress y no a un plugin. Eran dos fallos encadenados. Uno, en la API REST (CVE-2026-63030), dejaba saltarse la validación de datos. El otro, una inyección SQL en WP_Query (CVE-2026-60137), por sí solo tenía una nota de solo 5,9. Patchstack explica que, juntos, permitían a un visitante anónimo llegar a crear un administrador y, de ahí, a ejecutar código.
Aquí está la primera lección: la nota de cada pieza no dice lo que valen juntas. Una puntuación de 5,9 estaba dentro de una cadena que acababa en control total.
En los días posteriores, Patchstack bloqueó más de 65.000 intentos desde más de 1.500 direcciones IP distintas. WordPress.org activó actualizaciones forzadas para las webs afectadas, de modo que quien tenía activadas las actualizaciones automáticas recibió la corrección sin hacer nada.
CVE-2026-87902: el mismo día
Otra del núcleo, el 22 de septiembre. Patchstack vio el primer intento a las 11:49 UTC, el mismo día de la versión 7.1.2, y a las 15:34 el primer intento de escribir un archivo en el servidor. Eso sí, tenía condiciones: un tema con cierta carpeta y PHP con register_argc_argv activado. No todas las webs eran vulnerables en la práctica.
Elementor Pro: formularios con subida de archivos
CVE-2026-32475, un fallo en el campo de subida de archivos de los formularios de Elementor Pro (hasta la 4.2.1). Patchstack lo publicó el 19 de agosto, el día en que salió la 4.2.2, y recomienda mirar wp-content/uploads/elementor/forms/ por si hay archivos .php. Los informes sobre cuándo empezaron los ataques no coinciden entre sí, así que no lo cuento como ejemplo de «ataque el mismo día».
Bricksforge: atacado antes de que hubiera aviso
Aquí actualizar rápido no basta. Los ataques empezaron el 7 de octubre a las 21:47 UTC, antes del aviso público. Cuando no hay margen, lo que cuenta es haber mirado después si entraron.
All-in-One WP Migration y Everest Forms Pro: más matices
El primero (CVE-2026-19949) se corrigió en la 7.110. El NVD explica que la inyección SQL se aprovecha cuando un administrador restaura una copia. Tiene un 8,8 y, que yo haya podido confirmar, no figura en KEV. Del segundo (CVE-2026-3300, ejecución de código hasta la 1.9.12) hay informes de explotación que no he podido contrastar con una fuente primaria, así que lo dejo como pendiente de confirmar.
Qué enseña todo esto
1. La nota (CVSS) es un punto de partida, no un semáforo. Mide cómo de grave es el fallo sobre el papel. No dice si alguien lo está usando. Entre un 8,8 sin ataques confirmados y un 5,9 metido en una cadena de 9,8, la nota engaña. Preguntas más útiles:
- ¿Se puede explotar sin iniciar sesión?
- ¿Afecta a una instalación normal, o necesita una configuración rara?
- ¿Hay ataques observados o está en el catálogo KEV?
- ¿Uso yo ese componente, y con esa función activada?
2. La ventana es de horas. Quien lee el parche monta un escáner y lo apunta a todo internet. Esperar al «mantenimiento de fin de mes» deja una web crítica expuesta casi cuatro semanas.
3. No todo es urgente. WordPress 7.1.3 (6 de octubre) llevaba siete correcciones, y Patchstack dijo que no era una emergencia. Si todo es urgente, nada lo es, y la gente acaba sin actualizar.
4. Actualizar cierra la puerta, no echa a nadie. En Elementor Pro y en Bricksforge, quien entró antes sigue dentro.
El volumen: por qué no puedes leerlo todo
Wordfence publicó que, entre el 12 y el 18 de octubre, se divulgaron 497 vulnerabilidades en 327 plugins y 23 temas. La semana anterior, 654. Nadie puede leer eso cada semana.
La salida no es leer más, sino saber qué tienes instalado. De 500 avisos, a tu web le afectan los que coinciden con tu lista de plugins.
Una rutina realista para una web de empresa o una tienda
- Haz el inventario. Plugins, tema y versión del PHP. Borra los que no uses: cada plugin de más es una puerta más que vigilar.
- Decide quién vigila. Una persona concreta, no «alguien». Wordfence ofrece de forma gratuita su base de datos de vulnerabilidades, con API y avisos por webhook. Patchstack tiene su propia base abierta. Y INCIBE-CERT publica alertas en español.
- Dos carriles.
- *Urgente* (sin login, explotado o en KEV, y lo usas): copia, prueba rápida y actualización en 24 horas.
- *Rutinario*: una vez a la semana, con calma.
- Copia antes de tocar. Con restauración probada, y guardada fuera del servidor.
- Prueba en una copia (staging) si la web cobra. Un pedido de prueba completo, los correos y los formularios. En una web informativa, comprobar la portada y un formulario basta.
- Automatiza lo seguro. Las actualizaciones de seguridad del núcleo se aplican solas por defecto; déjalas así. Para plugins pequeños y de bajo riesgo, la actualización automática ahorra trabajo. Para el constructor, el pago y los plugins que tocan los pedidos, mejor a mano y probando.
- Los plugins premium van aparte. Elementor Pro, Bricksforge o Everest Forms Pro se actualizan desde la licencia del proveedor, no desde WordPress.org. Si la licencia caducó, el aviso puede no llegarte.
- Después de un fallo crítico, mira si entraron. Archivos
.phpenuploads, administradores nuevos, plugins que no instalaste.
Qué hacer según tu caso
Tu caso | Prioridad |
|---|---|
Web informativa, pocos plugins, nadie la mira | Actualizaciones automáticas de seguridad del núcleo activadas, revisión semanal y copia fuera del servidor |
Tienda WooCommerce | Staging, pedido de prueba tras actualizar y carril urgente de 24 h |
Usas constructores o formularios premium | Alta en el aviso del proveedor, licencia vigente y revisión de |
Gestionas varias webs | Inventario común y una sola persona que mire los avisos |
No tienes tiempo ni a quién encargárselo | Delegarlo, pero preguntando cuánto tardan en un fallo urgente |
Qué no sabemos
- Sin verificar: el momento exacto en que empezaron los ataques a Elementor Pro, y la explotación real de All-in-One WP Migration y Everest Forms Pro.
- Cifras de bloqueo: son intentos detectados por los sistemas de una empresa de seguridad, no cuántas webs han caído.
- Un estudio trimestral que circula en blogs, según el cual en tres de cuatro casos los ataques empezaron el día del parche, no he podido cotejarlo con Patchstack. Por eso uso solo los casos que sí he podido comprobar.
Y ahora, qué
Haz hoy el inventario y apunta quién mira los avisos. Es lo que menos cuesta y lo que más cambia.
En AGENCIA RSE, esto es parte del mantenimiento WordPress: vigilar los avisos, probar los cambios en una copia y comprobar el checkout después. Aun así, todo lo anterior se puede hacer por cuenta propia. Y si quieres una primera mirada desde fuera, hay pruebas gratuitas.
*Si ves un dato desactualizado, escríbenos y lo corregimos.*