# La Crisis de Vulnerabilidades del CMS: los Datos que Necesita tu Comité de Seguridad

> WordPress reveló 11.334 vulnerabilidades en 2025. La brecha de parcheo, el coste de las brechas y cinco casos universitarios para tu comité de riesgo.

**URL:** https://griddo.io/journal/crisis-vulnerabilidades-cms-universidades/
**Language:** Español
**Publicado:** 2026-09-10
**Autor:** Francis Vega
**Etiquetas:** security, architecture

---

## Puntos Clave

- **La tendencia se acelera, no se estabiliza:** las vulnerabilidades de WordPress se han multiplicado por más de cuatro entre 2022 y 2025, y el 91% procede de plugins, no del núcleo.
- **La brecha de parcheo es la métrica decisiva:** los atacantes escanean en 4 horas tras la divulgación; los sitios autoalojados tardan de media 14 días en parchear.
- **La educación paga el precio más alto por esa brecha:** el sector absorbe más ataques por organización que ningún otro, con un coste medio de brecha de 3,7 M$.

---

Si eres un CIO universitario presentando el caso para migrar de plataforma CMS, los argumentos arquitectónicos por sí solos no van a mover a un comité de gobierno. Necesitas datos que un comité de riesgo pueda cuantificar y que un CFO pueda incorporar a una decisión de inversión.

## WordPress: una crisis que se acelera

La tasa de divulgación de vulnerabilidades de WordPress se ha multiplicado por más de cuatro en cuatro años.

| Año | Vulnerabilidades nuevas | Crecimiento |
|------|-------------------|--------|
| 2022 | ~2.500 | Base |
| 2023 | ~5.948 | +138% |
| 2024 | 7.966 | +34% |
| 2025 | 11.334 | +42% |

*Fuentes: Patchstack (dato de 2025, febrero de 2026); Patchstack State of WordPress Security 2025 (dato de 2024); Wordfence 2024 Annual Report (que contabilizó 8.223 por CVE de forma independiente para 2024).*

Esta trayectoria no muestra señales de estabilizarse: en 2025, el 91% de las nuevas vulnerabilidades procedió de plugins, no del núcleo, continuando la tendencia de 2024, cuando la proporción ya era del 96% (7.633 fallos en plugins, 4% en temas y solo 7 en el núcleo). El núcleo es razonablemente seguro. El problema de fondo es la arquitectura monolítica que permite la ejecución de código de terceros en tiempo de ejecución. El Cross-Site Scripting supone en torno al 50% de todas las vulnerabilidades de WordPress, seguido del control de acceso roto (14,2%) y el CSRF (11,4%).

Tres datos merecen atención especial en cualquier evaluación de riesgo:

#### Lo primero que debería ver un comité de riesgo

- El **43%** de las vulnerabilidades de 2024 no requerían autenticación para explotarse: ni credenciales, ni sesión, solo una URL pública.
- El **52%** de los desarrolladores de plugins no publicó un parche antes de la divulgación pública, el hallazgo más preocupante del informe 2025 de Patchstack.
- El **33%** de todas las vulnerabilidades permaneció completamente sin parchear en el momento de la divulgación; Wordfence encontró un 35% aún sin parchear bien entrado 2025.

La escala de la explotación activa es igual de contundente. Wordfence bloqueó 54.000 millones de peticiones maliciosas en su red durante 2024: incluidos 9.000 millones de intentos de XSS y 1.100 millones de inyección SQL. La investigación de Sucuri encontró que WordPress supone el 95,5% de todas las infecciones de CMS detectadas, muy por encima de su cuota de mercado del 42,8%: los sitios WordPress son atacados de forma desproporcionada porque la economía de la vulnerabilidad favorece al atacante.

El perfil de Drupal es sustancialmente distinto: solo 8 avisos de seguridad del núcleo en 2024 y entre 100 y 125 avisos de módulos contribuidos al año. Pero Drupal 7 llegó a su fin de vida el 5 de enero de 2025, y las vulnerabilidades de Drupalgeddon (2014-2018) mostraron lo que ocurre cuando sí aparecen fallos de núcleo: más de 115.000 sitios vulnerables solo en 2018. Un volumen menor no significa inmunidad a la misma debilidad arquitectónica. Simplemente es una versión de combustión más lenta del mismo problema.

## La brecha de parcheo: la métrica que lo decide todo

La brecha de parcheo es el tiempo entre la divulgación de una vulnerabilidad y la aplicación del parche, y es la métrica que mejor predice si tu institución acabará comprometida.

**WordPress autoalojado:** 14 días de media para aplicar parches críticos. **Escaneo automatizado de atacantes:** empieza en las 4 horas siguientes a la divulgación.

Esa asimetría es la ventana por la que ocurren la mayoría de las brechas de CMS, y los datos que la rodean la empeoran: solo el 47% de los sitios WordPress ejecuta la última versión en un momento dado, alrededor del 80% de los sitios alojados ejecutan versiones desactualizadas del CMS (Patchman), y el 42,91% sigue en PHP 7.4, sin soporte desde noviembre de 2022.

Para una universidad que gestiona más de 50 instancias de WordPress entre facultades y departamentos (cada una mantenida por equipos con prioridades y ritmos de actualización distintos), la brecha de parcheo se acumula. Tu departamento más diligente parchea en 48 horas. El menos atento no se actualiza desde el semestre pasado. Al atacante le basta con encontrar el eslabón más débil.

## Educación: el sector más atacado del mundo

Check Point Research sitúa a la educación como el **sector #1 más atacado a nivel mundial**, absorbiendo 4.388 ataques por organización y semana: un aumento interanual del 31%. El Verizon 2025 DBIR documenta 1.075 incidentes de seguridad y 851 brechas confirmadas en educación. El ransomware estuvo presente en el 44% de las brechas educativas, frente al 32% anterior, y la explotación de vulnerabilidades creció hasta el 20% de los vectores de acceso inicial.

El impacto financiero: el informe de IBM sitúa el coste medio de una brecha en educación en **3,7 millones de dólares**. Los datos de Comparitech muestran que la demanda media de rescate en el primer semestre de 2025 alcanzó 1,6 millones de dólares. Las universidades han aumentado sus presupuestos de ciberseguridad más de un 70% en cinco años (Moody's), y el volumen de ataques sigue superando esa inversión.

¿Por qué específicamente la educación? Las universidades mantienen un gran número de dominios y subdominios, gestionados por departamentos con niveles de expertise en seguridad muy dispares. Los investigadores describen ese patrón como un archipiélago de superficies de ataque mantenidas de forma inconsistente. Cada sitio WordPress departamental es una posible puerta de entrada; cada micrositio olvidado, una puerta sin cerrar.

## Cuando ocurre: cinco casos universitarios

#### University of Greenwich (Reino Unido): la brecha causada por CMS por excelencia

En 2016, un grupo de hackers explotó un micrositio CMS abandonado, construido para un congreso de 2004. El sitio sin proteger dio acceso al servidor web principal, comprometiendo datos personales de 19.500 estudiantes, empleados y antiguos alumnos. La Oficina del Comisionado de Información del Reino Unido impuso una multa de 120.000 libras: la primera sanción a una universidad bajo la ley británica de protección de datos.

**University of Michigan: migración forzosa de CMS (2024).** La universidad anunció que los sitios WordPress y Drupal comprometidos en su infraestructura AFS debían migrar a una plataforma gestionada o desconectarse, y prohibió por completo las nuevas instalaciones autoalojadas. Cuando una gran universidad de investigación ordena migrar fuera del CMS autoalojado, la señal política es clara.

**Stanford University: compromiso en serie (2023).** Tres incidentes distintos en un año: una mala configuración web expuso los datos de solicitud de doctorado de unas 900 personas, una brecha de ransomware pasó cuatro meses sin detectarse y comprometió 27.000 registros (incluidos números de la seguridad social y datos biométricos), y Stanford se vio además afectada por el ataque a la cadena de suministro de MOVEit. Tres vectores, una institución, un hilo común: un parque web descentralizado con prácticas de seguridad inconsistentes.

**Texas Tech University Health Sciences Center (2024).** El grupo de ransomware Interlock mantuvo acceso no autorizado durante 12 días, exfiltrando datos de 1,4 millones de personas en dos campus. El tiempo de permanencia prolongado apunta a fallos de monitorización típicos de entornos de TI complejos y descentralizados.

**MOVEit Transfer: cerca de 900 universidades afectadas (2023).** Un día cero de inyección SQL en la herramienta MOVEit Transfer de Progress Software expuso números de la seguridad social, identificadores de estudiante y expedientes académicos. MOVEit no es un CMS, pero el patrón del ataque (inyección SQL en una aplicación expuesta a la web) refleja con precisión los vectores de ataque más comunes contra un CMS.

Todos los casos anteriores comparten un factor estructural: la propia arquitectura (monolítica, acoplada, federada sin gobernanza) crea las condiciones para la brecha. Greenwich no sufrió la brecha porque alguien olvidara parchear; la sufrió porque la arquitectura permitía que un micrositio olvidado alcanzara la base de datos de producción. Michigan no ordenó la migración porque los parches fueran lentos; la ordenó porque el modelo autoalojado genera un volumen de riesgo inmanejable.

## Tu siguiente paso

La pregunta para los CIOs universitarios no es si seguir defendiendo esta arquitectura con presupuestos crecientes y retornos decrecientes. Es si abordar la raíz estructural del problema. [El nuevo perímetro de seguridad de la arquitectura web de una universidad](/journal/perimetro-seguridad-arquitectura-cms-universidad/) es el punto de partida de esa conversación.

[Solicita una Revisión de Seguridad Arquitectónica](/demo/)

## Fuentes

[Patchstack State of WordPress Security 2025](https://patchstack.com/whitepaper/state-of-wordpress-security-in-2024/) | [Wordfence 2024 Annual WordPress Security Report](https://www.wordfence.com/) | [Verizon 2025 Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/dbir/) | [Check Point 2025 Cyber Security Report](https://www.checkpoint.com/cyber-hub/cyber-security/what-is-cyber-security/cyber-security-report/) | [Sanción de la ICO a University of Greenwich](https://ico.org.uk/action-weve-taken/enforcement/university-of-greenwich/)

---

## Relacionados en Esta Serie

- [El Nuevo Perímetro de Seguridad: Por Qué los CIOs Universitarios Están Repensando la Arquitectura CMS](/journal/perimetro-seguridad-arquitectura-cms-universidad/)
- [Cómo la Arquitectura Headless Elimina Clases de Ataque: un Análisis con el Marco OWASP](/journal/arquitectura-headless-elimina-clases-ataque/)
- [Deuda de Mantenimiento, Economía del Parcheo y Arquitectura de Cumplimiento](/journal/deuda-mantenimiento-cumplimiento-arquitectura/)

---

*Generado desde [La Crisis de Vulnerabilidades del CMS: los Datos que Necesita tu Comité de Seguridad](https://griddo.io/journal/crisis-vulnerabilidades-cms-universidades/)*