Un CVE WordPress es una vulnerabilidad de seguridad documentada y registrada oficialmente en la base de datos Common Vulnerabilities and Exposures, que afecta a WordPress core, plugins o temas. Cada CVE tiene un identificador único y una puntuación de severidad CVSS que permite evaluar el riesgo. En 2025 se registraron más de 48.000 CVEs globales, y WordPress concentró miles de ellos, mayormente en plugins.
En 30 segundos
- Un CVE es un identificador único para vulnerabilidades de seguridad; el CVSS (0-10) mide qué tan grave es.
- El 90% de las vulnerabilidades en WordPress vienen de plugins, no del core.
- En una sola semana de mayo de 2026 se reportaron 87 vulnerabilidades en el ecosistema WordPress.
- Las principales bases de datos para consultar CVEs de WordPress son Patchstack, WPScan y Wordfence Intelligence.
- Actualizar plugins y temas es la medida más efectiva para evitar que un CVE te impacte.
¿Qué es un CVE? Definición y por qué importa en WordPress
CVE son las siglas de Common Vulnerabilities and Exposures, un sistema estándar de identificación de fallos de seguridad gestionado por MITRE Corporation. Cada entrada en la base de datos CVE corresponde a una vulnerabilidad específica, documentada con un ID del tipo CVE-AÑO-NÚMERO, una descripción técnica y referencias a los parches disponibles.
El punto es que WordPress, por ser la plataforma más usada del mundo (más del 40% de todos los sitios), es también el objetivo más frecuente. Y el vector de ataque número uno no es WordPress en sí: son los plugins. Según Patchstack, alrededor del 90% de todas las vulnerabilidades reportadas en WordPress provienen de extensiones de terceros, no del core.
Diferenciá una vulnerabilidad teórica de un CVE registrado: no todo fallo de seguridad termina en un CVE público. Para que eso pase, alguien tiene que reportarlo, MITRE tiene que aceptarlo, y el desarrollador tiene que confirmar la existencia del problema (o un investigador tiene que probarlo). Un CVE sin parche es lo que se llama un 0-day.
CVE vs CVSS: entendé la diferencia
Mucha gente los confunde. Son dos cosas distintas.
El CVE es solo el identificador, el número de expediente del fallo. El CVSS (Common Vulnerability Scoring System) es la puntuación que mide qué tan grave es ese fallo, en una escala de 0 a 10.
| Rango CVSS | Severidad | Implicancia |
|---|---|---|
| 9.0 – 10.0 | Crítico | Explotación remota sin autenticación, impacto máximo |
| 7.0 – 8.9 | Alto | Compromiso significativo, requiere poca interacción |
| 4.0 – 6.9 | Medio | Explotación posible con condiciones adicionales |
| 0.1 – 3.9 | Bajo | Impacto limitado o muy difícil de explotar |
Acá viene algo que mucha gente no considera: un CVSS alto en un plugin que usa el 0.01% de los sitios es mucho menos urgente que un CVSS medio en un plugin con 5 millones de instalaciones activas. La puntuación mide explotabilidad técnica, no impacto real en tu sitio. CVE-2025-6389 tiene CVSS 9.8 en Sneeit Framework; CVE-2024-10924 (Really Simple Security, más de 4 millones de sitios) también era crítico. El segundo claramente era más urgente por escala de impacto.
El ciclo de vida de un CVE WordPress
No todos los CVEs nacen iguales ni llegan al mismo tiempo. El proceso tiene cinco fases bien definidas:
- Descubrimiento: un investigador de seguridad (o cada vez más, una herramienta de análisis automatizado) identifica un fallo en el código de un plugin o tema.
- Notificación responsable: el investigador avisa al desarrollador de forma privada y le da entre 30 y 90 días para publicar un parche antes de revelar el problema públicamente.
- Publicación: se asigna el ID CVE, se publica la descripción técnica y la puntuación CVSS.
- Parche disponible: el desarrollador lanza la actualización corregida.
- Explotación activa: atacantes empiezan a usar el CVE publicado para comprometer sitios que todavía no actualizaron.
¿Y qué pasa si el desarrollador ignora la notificación? El investigador publica igual, y el fallo pasa a ser un 0-day: una vulnerabilidad conocida públicamente sin parche disponible. A finales de 2025, el CVE-2025-11833 en Post SMTP afectó a más de 400.000 sitios. Otro caso emblemático: CVE-2024-10924 en Really Simple Security, con más de 4 millones de instalaciones, donde el plugin que debía proteger tu sitio tenía una vulnerabilidad de autenticación crítica (sí, así como lo escuchás).
Vulnerabilidades críticas recientes: casos 2025-2026
Para que no quede todo en teoría, algunos casos concretos de CVE WordPress que vale la pena conocer:
CVE-2025-6389 — Sneeit Framework, CVSS 9.8. Remote Code Execution sin autenticación previa. El tipo de vulnerabilidad que hace que un atacante pueda ejecutar código arbitrario en el servidor. Si tu sitio usa temas o plugins basados en este framework y no actualizaste, estás expuesto. Tema relacionado: protección contra ataques DDoS.
CVE-2025-5947 — Auth bypass en múltiples plugins, CVSS 9.8. Un bypass de autenticación permite acceder a funciones de administrador sin credenciales. Este tipo de fallo es especialmente peligroso porque no requiere que el atacante conozca ninguna contraseña.
CVE-2025-8489 — King Addons for Elementor, registro no autorizado de administradores. Si tenés este plugin, un atacante podría registrarse como admin en tu sitio.
CVE-2025-5394 — Tema Alone, vulnerabilidad con impacto en sitios que usan este theme para portfolios y páginas de servicios.
¿Alguien verificó la escala real de explotación de estos CVEs de forma independiente? En algunos casos sí, en otros todavía están bajo análisis activo. El reporte de vulnerabilidades críticas de mayo 2026 que publicamos acá cubre 87 vulnerabilidades reportadas en una sola semana, lo que da una idea de la cadencia del problema.
Dónde encontrar información sobre CVE WordPress
No todas las bases de datos son iguales. Las principales opciones:
Patchstack Database
Patchstack tiene más de 48.000 entradas de vulnerabilidades WordPress. Es la base de datos más actualizada en velocidad de publicación (suelen publicar CVEs antes que otros). Ideal para búsquedas rápidas por nombre de plugin. Tiene plan gratuito para búsqueda manual y plan pago con alertas automáticas.
WPScan
WPScan combina base de datos de vulnerabilidades con herramienta de escaneo en línea de comandos. Si querés auditar tu propio sitio de forma automatizada, WPScan es la opción. Tiene API con tier gratuito (25 requests/día) y planes pagos para uso intensivo.
Wordfence Intelligence
Wordfence Intelligence ofrece datos en tiempo real sobre vulnerabilidades activamente explotadas. Útil si ya usás Wordfence como firewall, porque la integración es directa.
INCIBE y fuentes institucionales
Para quienes operan en España, el INCIBE-CERT publica boletines periódicos sobre vulnerabilidades que incluyen entradas de WordPress. Útil como capa adicional, aunque más lento que Patchstack o Wordfence.
Cómo proteger tu sitio WordPress de CVEs
Actualizá los plugins. Es el 80% del trabajo. El resto es capa adicional de defensa, pero si no actualizás, ninguna otra medida alcanza. Más contexto en validar datos en formularios.
Dicho esto, el listado completo de medidas que realmente hacen diferencia, en orden de impacto:
- Actualizaciones automáticas para core, plugins y temas. En WordPress podés activarlas desde el panel o con código en wp-config.php. Ojo: algunos plugins de página builder tienen actualizaciones que rompen cosas, así que conviene tener backups antes.
- Eliminar plugins obsoletos o sin mantenimiento. Un plugin sin actualizar hace 2 años es una vulnerabilidad esperando ser publicada. Si no lo usás activamente, desactivalo y borralo.
- WAF (Web Application Firewall). Wordfence o equivalente. Bloquea intentos de explotación conocidos incluso antes de que actualices.
- Backups diarios fuera del servidor. Si alguien explota un CVE y compromete el sitio, necesitás poder volver a un estado limpio. WPVivid, por ejemplo, te permite enviar backups automáticos a Google Drive.
- Monitoreo de vulnerabilidades activo. El plugin WPVulnerability que mencionamos en este blog te avisa cuando uno de tus plugins tiene un CVE publicado.
- Auditorías periódicas. Una vez por trimestre, revisá manualmente qué plugins tenés instalados, cuándo fue la última actualización de cada uno, y si el desarrollador sigue activo.
Una aclaración que muchos hosts no te dicen: el proveedor de hosting gestiona la infraestructura del servidor, pero la responsabilidad de actualizar plugins y temas es tuya. Si usás un hosting como donweb.com con WordPress administrado, verificá exactamente qué incluye el plan porque la diferencia entre hosting compartido y managed WordPress puede ser importante acá.
Herramientas para monitorear y prevenir CVEs
| Herramienta | Tipo | Plan gratuito | Mejor para |
|---|---|---|---|
| Patchstack | Base de datos + alertas | Sí (manual) | Monitoreo pasivo, búsqueda por plugin |
| Wordfence | Firewall + escáner | Sí (limitado) | Defensa activa, bloqueo en tiempo real |
| WPScan | Escáner CLI + base de datos | Sí (25 req/día) | Auditorías técnicas, automatización |
| WPVulnerability | Plugin de monitoreo | Sí | Alertas dentro del panel WP |
| SolidWP (iThemes) | Suite de seguridad | No | Reportes y hardening integrado |
Una combinación razonable para la mayoría de sitios: Patchstack para monitoreo pasivo de CVEs, Wordfence para defensa activa y bloqueo de exploits, y WPScan cuando necesitás hacer una auditoría puntual. No necesitás los tres corriendo simultáneamente en todos los sitios (medio que se superponen y consumen recursos), pero sí conviene tener al menos dos capas activas.
Errores comunes al gestionar CVEs en WordPress
Error 1: creer que el CVSS lo dice todo. Un CVSS 4.5 en un plugin con 3 millones de instalaciones puede ser más urgente que un CVSS 9.0 en un plugin que usa el 0.1% del mercado. La puntuación mide explotabilidad técnica, no tu riesgo real. Evaluá siempre: ¿qué tan popular es el plugin afectado? ¿Está siendo explotado activamente?
Error 2: «yo no tengo nada importante, nadie me va a atacar». Los ataques masivos a WordPress no son dirigidos: son automatizados. Un bot no sabe si tu sitio tiene información valiosa o no; escanea miles de sitios buscando versiones vulnerables y ejecuta el exploit en los que encuentra. El tamaño del sitio no te protege. Sobre eso hablamos en extensiones seguras para WordPress.
Error 3: desactivar un plugin sin borrarlo. Un plugin desactivado pero instalado sigue siendo código presente en el servidor. En ciertos tipos de vulnerabilidades (file inclusion, por ejemplo), el código puede ser explotado aunque el plugin esté desactivado. Si no lo usás, borralo.
Error 4: confiar en el plugin de seguridad sin mantenerlo actualizado. CVE-2024-10924 en Really Simple Security es el ejemplo perfecto: el plugin pensado para protegerte tenía una vulnerabilidad crítica propia. Los plugins de seguridad también necesitan actualizarse (y auditarse).
Preguntas Frecuentes
¿Qué es un CVE en WordPress?
Un CVE en WordPress es una vulnerabilidad de seguridad registrada oficialmente en la base de datos Common Vulnerabilities and Exposures, que afecta a WordPress core, un plugin o un tema. Cada CVE tiene un identificador único (formato CVE-AÑO-NÚMERO), una descripción técnica del fallo y una puntuación CVSS que indica su severidad. La mayoría de CVEs WordPress afectan plugins de terceros, no el núcleo de WordPress.
¿Cómo sé si mi sitio WordPress está afectado por un CVE?
Buscá el nombre de cada plugin que tenés instalado en Patchstack o WPScan y verificá si tiene vulnerabilidades publicadas para la versión que usás. También podés instalar el plugin WPVulnerability, que hace esta verificación automáticamente dentro de tu panel de WordPress. Si el plugin instalado tiene una versión menor a la que corrige el CVE, tu sitio está expuesto.
¿Dónde encuentro información actualizada sobre vulnerabilidades de WordPress?
Las tres fuentes más completas y actualizadas son: Patchstack (más de 48.000 entradas, actualizaciones rápidas), Wordfence Intelligence (datos en tiempo real sobre exploits activos) y WPScan (base de datos con herramienta de escaneo integrada). Para Argentina y España, el INCIBE-CERT también publica boletines periódicos, aunque con menor velocidad de actualización.
¿Qué diferencia hay entre CVE y CVSS?
CVE es el identificador único de la vulnerabilidad, como un número de expediente. CVSS es la puntuación de severidad, en escala de 0 a 10, que mide qué tan fácil es explotar ese fallo y qué impacto tiene. Un CVE sin puntuación CVSS existe pero no tiene clasificación de riesgo asignada. Podés tener un CVE con CVSS 9.8 (crítico) y otro con CVSS 3.1 (bajo); el CVSS te dice cuál requiere atención más urgente, pero siempre considerando cuántos sitios usa el plugin afectado.
¿Cómo proteger mi WordPress de vulnerabilidades CVE?
Las medidas más efectivas son: activar actualizaciones automáticas para plugins y temas, eliminar plugins que no usás o que llevan más de un año sin actualizaciones del desarrollador, instalar un WAF como Wordfence, y configurar backups diarios fuera del servidor. Mantener los plugins actualizados resuelve el 80% del riesgo de CVE porque la mayoría de los exploits activos apuntan a versiones antiguas, no a 0-days.
Conclusión
El ecosistema de CVE WordPress en 2026 es más activo que nunca: 87 vulnerabilidades reportadas en una sola semana de mayo no es una anomalía, es la cadencia normal. La buena noticia es que la mayoría de los ataques exitosos no explotan 0-days sofisticados sino CVEs publicados hace semanas o meses en plugins que nadie actualizó.
La diferencia entre un sitio comprometido y uno que safó generalmente no está en el hosting ni en el firewall. Está en si los plugins estaban actualizados el día que el bot pasó escaneando. Activá las actualizaciones automáticas, borrá lo que no usás, y revisá Patchstack o Wordfence periódicamente. Con eso cubrís la gran mayoría del riesgo real.
Fuentes
- Wordfence Intelligence — base de datos de vulnerabilidades WordPress en tiempo real
- Patchstack Database — más de 48.000 entradas de vulnerabilidades WordPress
- WPScan — escáner de seguridad y base de datos de CVEs WordPress
- Seguridadenwordpress.com — Vulnerabilidades críticas en plugins WordPress 2026
- INCIBE-CERT — Alertas tempranas de vulnerabilidades