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:

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 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 es el punto de partida de esa conversación.

Solicita una Revisión de Seguridad Arquitectónica

Relacionados en Esta Serie