Vulnerabilidades más explotadas en 2026: por qué tu ciclo de parcheo llega tarde

Si gestionas la seguridad de una empresa tecnológica, conoces la rutina: llega el boletín de seguridad, se abre un ticket, se planifica la ventana de mantenimiento y el parche entra en el ciclo mensual. Ese proceso, que durante años ha sido la práctica razonable, está empezando a fallar por diseño. Y no es una opinión: es lo que se desprende de los datos.

El informe State of Exploitation 1H-2026 de VulnCheck documenta 495 vulnerabilidades con explotación conocida (KEV) durante el primer semestre de 2026. La cifra por sí sola no dice mucho; lo relevante es la velocidad con la que estas vulnerabilidades pasan de la publicación del CVE a la explotación real en la naturaleza. Y esa velocidad ha cambiado lo suficiente como para replantear cómo priorizamos.

Qué dicen los números del primer semestre de 2026

Vamos a los datos concretos, sin redondear:

• 495 vulnerabilidades con explotación conocida en 1H-2026.
• El 23,4% ya se explotaba el mismo día de la publicación del CVE o antes (en 2025 era el 28,9%).
• La mediana desde la publicación del CVE hasta la explotación conocida cae de 120 días en 2025 a 80 días en 1H-2026.
• Unas 200 llegaron a explotarse en menos de 31 días.
• Los gestores de contenido (WordPress, Drupal, Ghost, Kentico Xperience) concentran un tercio de todo lo explotado.
• Solo 12 de las 495 entraron en el catálogo KEV de CISA.

Hay dos lecturas que merece la pena desarrollar, porque tienen implicaciones operativas directas.

El día cero del boletín ya no es un margen seguro

Que casi una de cada cuatro vulnerabilidades se explote el mismo día en que se publica el CVE —o antes— significa que el atacante no está esperando a tu ventana de mantenimiento. El descenso del 28,9% al 23,4% en la explotación en día cero no debería leerse como una mejora: la mediana global se ha desplomado de 120 a 80 días, y unas 200 vulnerabilidades se explotaron en menos de 31 días. Es decir, la explotación temprana se está concentrando y acelerando en un tramo más amplio de vulnerabilidades.

La consecuencia es incómoda pero clara: un ciclo de parcheo mensual asume que dispones de semanas de margen que, para una parte creciente del catálogo, ya no existen. No estamos diciendo que haya que parchear todo en 24 horas —sería inviable y contraproducente—, sino que la priorización basada exclusivamente en el calendario está desalineada con el comportamiento real de los atacantes.

El CMS es el eslabón que casi nadie vigila con rigor

El dato que más debería preocupar a una empresa con presencia web corporativa es que un tercio de todo lo explotado son gestores de contenido. WordPress, Drupal, Ghost y Kentico Xperience aparecen de forma recurrente. Y aquí hay un problema estructural: el CMS corporativo suele estar fuera del radar del equipo de seguridad porque «lo lleva marketing» o «lo mantiene la agencia».

Ese ángulo muerto es exactamente donde se concentra la explotación. Un WordPress con plugins desactualizados, un theme abandonado o un panel de administración expuesto es, hoy, uno de los vectores de entrada más rentables para un atacante oportunista. No requiere una campaña sofisticada: requiere un escáner masivo y un exploit público. La superficie web corporativa es, según estos datos, el primer sitio donde deberías mirar.

El problema de apoyarse solo en el catálogo KEV de CISA

Muchos equipos usan el catálogo KEV de CISA como fuente de priorización. Es una práctica sensata, pero tiene un límite que el informe de VulnCheck deja en evidencia: solo 12 de las 495 vulnerabilidades con explotación conocida entraron en el KEV de CISA durante el semestre.

Si tu proceso de priorización dice «parcheamos lo que esté en el KEV de CISA», estás cubriendo una fracción mínima de lo que realmente se está explotando. No es un fallo del catálogo —CISA tiene criterios propios de inclusión y un ámbito concreto—, sino un error de expectativas por parte de quien lo usa como lista única de verdad. La inteligencia de explotación es más amplia que cualquier catálogo individual, y depender de una sola fuente genera una falsa sensación de cobertura.

La recomendación práctica es combinar fuentes: KEV de CISA, feeds de explotación como el de VulnCheck, y —esto es clave— conocimiento propio de qué está realmente expuesto y es alcanzable en tu infraestructura. Porque una vulnerabilidad crítica en un componente que no está expuesto ni es alcanzable tiene una prioridad muy distinta a la misma vulnerabilidad en tu web pública.

Cómo esto se traduce en tu programa de seguridad

El marco MITRE ATT&CK sitúa la explotación de aplicaciones públicas (T1190) como una de las técnicas iniciales más habituales, y los datos de 1H-2026 lo confirman con números. Alinear tu programa con esta realidad implica varias cosas:

1. Inventariar de verdad la superficie web. No puedes proteger lo que no sabes que existe. Subdominios olvidados, entornos de staging accesibles, un WordPress institucional de una campaña de hace tres años. Todo eso cuenta.
2. Diferenciar «vulnerable» de «explotable». Un CVSS alto no equivale a riesgo real si el componente no es alcanzable. Al revés, un CVSS medio en tu web pública con exploit disponible es una emergencia.
3. Acortar el ciclo para lo que está expuesto e internet-facing. El parcheo mensual puede seguir valiendo para sistemas internos segmentados; para la superficie web pública, no.
4. Validar de forma continua, no puntual. Los controles CIS y frameworks como PTES insisten en la verificación recurrente. Una foto anual no capta un panorama que se mueve a 80 días de mediana.

Aquí es donde el pentesting aporta lo que ningún escáner ni catálogo da por sí solo: la validación de qué es realmente alcanzable desde fuera. Un servicio de pentesting web ejecutado con metodología OWASP y por analistas certificados OSCP no se limita a listar CVEs; determina qué se puede encadenar, qué está expuesto de verdad y qué impacto tendría un compromiso. En CISEC complementamos las evaluaciones puntuales con nuestra plataforma de pentesting continuo AISAC, precisamente porque el problema que describe VulnCheck es de velocidad y de ventana temporal, no solo de recuento de vulnerabilidades.

Lo que el pentesting sí hace (y lo que no)

Seamos honestos: el pentesting no sustituye al parcheo. Si tienes un CVE explotable en tu WordPress, la solución es actualizar, no repetir un test. Lo que el pentesting hace es responder a la pregunta anterior: ¿qué tengo expuesto y qué es realmente alcanzable antes de que lo encuentre otro?

Ese orden importa. Parchear a ciegas es caro e ineficiente; parchear con un mapa preciso de tu superficie expuesta y de las rutas de ataque viables convierte un proceso reactivo en uno priorizado por riesgo real. Los datos de 1H-2026 dicen que el margen se estrecha; el pentesting te dice dónde gastar ese margen.

Preguntas frecuentes

Si parcheamos rápido, ¿necesitamos pentesting?

Sí, porque son cosas distintas. El parcheo cierra vulnerabilidades conocidas; el pentesting descubre qué está expuesto, qué configuraciones inseguras existen y qué rutas de ataque son viables aunque cada componente esté al día. El 23,4% de explotación en día cero significa, además, que siempre habrá una ventana en la que el parche no existe todavía: saber qué hay detrás de esa exposición reduce el impacto.

¿Cada cuánto deberíamos probar nuestra web corporativa?

Una evaluación anual es el mínimo razonable, pero con una mediana de explotación de 80 días y un tercio de la explotación concentrada en CMS, la superficie web pública se beneficia de una validación más frecuente o continua. Lo ideal es combinar un pentest en profundidad periódico con monitorización continua de la superficie expuesta.

¿Basta con seguir el catálogo KEV de CISA para priorizar?

No. Según VulnCheck, solo 12 de las 495 vulnerabilidades con explotación conocida en 1H-2026 entraron en el KEV de CISA. Es una fuente valiosa, pero insuficiente como criterio único. Conviene cruzarla con otros feeds de explotación y, sobre todo, con conocimiento propio de qué es alcanzable en tu infraestructura.