¿Cuántas vulnerabilidades tiene realmente una infraestructura cuando una herramienta de seguridad muestra miles de alertas? La cifra del panel no basta para responder. En un análisis con Wazuh fechado el 14 de octubre de 2026, 17.408 registros tenían una clasificación de severidad; 12.519 eran críticos o altos. Al comprobar los identificadores almacenados en el indexador, esos 12.519 registros correspondían a 2.229 CVE diferentes.
Esto no demuestra que las alertas restantes sean falsas. Demuestra por qué debemos separar registros, identificadores, sistemas afectados y vulnerabilidades efectivamente aplicables. La investigación que sigue explica cómo se obtuvo el recuento, qué reveló un caso concreto y, sobre todo, qué conclusiones no permiten extraer los datos.
1. El punto de partida: 17.408 registros clasificados
| Severidad | Registros |
|---|---|
| Crítica | 1.788 |
| Alta | 10.731 |
| Media | 4.511 |
| Baja | 378 |
| Total | 17.408 |
Los registros críticos y altos sumaban 12.519. La primera precaución fue comprobar que el conjunto de datos consultado coincidiera con los filtros del panel: no sería válido comparar cifras de diferentes momentos, agentes o ámbitos de consulta. El recuento realizado sobre el indexador reprodujo exactamente los 1.788 registros críticos y los 10.731 altos.
Datos agregados · 14/10/2026
1.788Alta
10.731Media
4.511Baja
378
Escala relativa al mayor valor (alta). Registros, no vulnerabilidades confirmadas.
2. Metodología: contar CVE distintos, no solo apariciones
La consulta se realizó en modo lectura sobre los índices de estado de vulnerabilidades de Wazuh/OpenSearch, utilizando los campos vulnerability.id y vulnerability.severity y preservando el mismo alcance del panel de origen. No se alteró ningún agente, paquete, configuración ni documento.
Primero se utilizó una agregación de cardinalidad con precisión elevada, que indicó 2.229 identificadores CVE diferentes. Como esa operación proporciona una estimación, el recuento se repitió mediante una agregación composite paginada. El recorrido obtuvo cuatro páginas de 500 CVE y una quinta de 229; una consulta final no devolvió más resultados. La suma de documentos asociados también coincidió con los 12.519 registros iniciales.
| Métrica | Resultado |
|---|---|
| Registros críticos y altos | 12.519 |
| CVE únicos, recuento exacto | 2.229 |
| Apariciones adicionales de CVE repetidos | 10.290 |
| Registros por CVE, de media | 5,62 |
| Proporción de apariciones adicionales | 82,2 % |
Ese 82,2 % no es una tasa de falsos positivos. Es la proporción de registros que excede de una primera aparición por cada identificador único. Un mismo CVE puede estar presente en diversos equipos y asociarse a varios paquetes de una instalación; todas esas detecciones podrían tener fundamento. Tampoco puede deducirse cuántos CVE son explotables a partir del número de identificadores.
Comparación del mismo conjunto de datos
10.290 apariciones adicionales de identificadores ya contados (82,2 % de los registros).
Las repeticiones no son automáticamente falsos positivos; pueden afectar a distintos agentes o paquetes.
3. Estudio de caso: CVE-2026-28417 en Vim
Para ir más allá de las estadísticas analizamos CVE-2026-28417, relacionado con el complemento estándar netrw de Vim. La vulnerabilidad puede permitir la ejecución de comandos con los privilegios del proceso si concurren determinadas condiciones y se procesa una URL manipulada. No implica una explotación automática o remota de todas las instalaciones de Vim.
En el conjunto estudiado aparecían 14 registros asociados al CVE. Al agrupar por identificador de agente —sin publicar ni conservar esos identificadores en los resultados divulgados— se confirmó que correspondían a 7 agentes diferentes, con dos paquetes asociados al mismo CVE en cada uno. El resumen es sencillo: 14 registros → 7 agentes → 1 CVE.
Esta distinción permite interpretar los contadores correctamente. Reducir catorce apariciones a un CVE único no elimina siete posibles instalaciones afectadas ni transforma automáticamente las detecciones en falsos positivos.
4. Lo que confirmó Debian y lo que no confirmó
La comprobación de las versiones con el registro oficial de seguridad de Debian mostró que las ramas Bookworm (Debian 12) y Trixie (Debian 13) figuraban con el CVE abierto, sin versión corregida indicada para esas ramas en la fecha del análisis. En cambio, Forky y Sid figuraban corregidas desde la versión del paquete fuente 2:9.2.0119-1.
Por tanto, las coincidencias de versiones observadas estaban respaldadas por el estado publicado por Debian. No teníamos fundamento para descartarlas como simples errores del escáner. Pero tampoco se había demostrado la explotabilidad efectiva en cada uno de los siete agentes: para eso hace falta comprobar la disponibilidad del componente afectado, las condiciones de uso, la exposición y los controles existentes.
Como precaución general ante este fallo, conviene evitar abrir con Vim URL o recursos remotos de origen no confiable que puedan activar el componente afectado y consultar las actualizaciones de seguridad de la distribución. No afirmamos que esa medida se haya aplicado o verificado en los agentes analizados.
5. Ubuntu y el problema de comparar solamente números de versión
La segunda parte del caso mostró por qué no basta con comparar la versión principal del programa con la versión corregida que anuncia el desarrollador. Las distribuciones Linux pueden incorporar parches de seguridad a su propia rama del paquete —una práctica conocida como backporting— sin adoptar todas las novedades de una nueva versión principal.
Según el aviso de seguridad de Ubuntu, Ubuntu 24.04 documentaba la corrección de CVE-2026-28417 desde el paquete 2:9.1.0016-1ubuntu7.10, con actualizaciones posteriores relativas a la corrección. En una comprobación independiente se identificó una instalación con 2:9.1.0016-1ubuntu7.20: seguía mostrando Vim 9.1 y conservaba archivos del complemento netrw, pero su versión del paquete era posterior a las actualizaciones de seguridad documentadas.
La mera presencia de un complemento y una numeración principal aparentemente antigua no demuestra que el paquete siga sin parchear. Hay que verificar la revisión específica y los avisos publicados por la distribución, incluidos los que corrigen regresiones de parches anteriores. El contraste Ubuntu no forma parte del recuento de los siete agentes Debian; es una comprobación independiente utilizada para ilustrar el papel de los parches de distribución.
6. La severidad es un dato de entrada, no una sentencia
El mismo CVE aparecía clasificado como alto en los registros de Wazuh, mientras que Ubuntu mostraba una prioridad media y CVSS 4,4. No basta con elegir una cifra y descartar la otra: las fuentes pueden aplicar metodologías y criterios diferentes, y el riesgo operativo exige un análisis particular.
Conviene separar tres operaciones: detectar una coincidencia con una vulnerabilidad conocida; validar si el producto, el paquete y su estado de corrección realmente están afectados; y evaluar el riesgo en función de la exposición, las condiciones de explotación y el impacto. Una puntuación ayuda a priorizar, pero no sustituye el contexto.
7. Lo que sabemos y lo que todavía no sabemos
Las evidencias permiten afirmar que se contaron exactamente 12.519 registros críticos y altos agrupados en 2.229 CVE únicos; que un CVE aparecía en 14 registros asociados a siete agentes; y que las versiones Debian detectadas pertenecían a ramas que el fabricante aún clasificaba como vulnerables en la fecha consultada. También quedó documentado cómo Ubuntu publicaba correcciones del mismo CVE en paquetes que seguían mostrando Vim 9.1.
Sin embargo, no se validaron individualmente los 2.229 CVE. No podemos afirmar cuántos son explotables, cuántos están mitigados o cuántos acabarían descartándose tras nuevas comprobaciones. Tampoco se verificaron las condiciones de explotación del caso Vim en los siete agentes. Cualquier cifra de «problemas reales confirmados» sería, a estas alturas, injustificada.
Reconocer estas limitaciones no debilita el análisis: es precisamente lo que diferencia una interpretación fundamentada de una conclusión apresurada.
8. Del inventario a las decisiones de seguridad
Un informe de cientos de páginas puede aportar mucho detalle y, sin embargo, no responder a la pregunta que más interesa a una empresa: ¿qué debemos corregir primero y por qué? Para responder hacen falta referencias verificables, versiones exactas, información de fabricantes, condiciones de aplicación y una priorización razonada.
En Tecnidom trabajamos en esa dirección durante el desarrollo de AuditCore, nuestra plataforma de auditoría de ciberseguridad: automatizar progresivamente verificaciones respaldadas por evidencias y dejar claramente identificados los hallazgos que todavía necesitan revisión técnica. No se trata de rebajar contadores ni de descartar detecciones sin justificación, sino de elaborar informes que permitan actuar con criterio.
Conclusión: detectar es el principio, no el final
El número de alertas no mide directamente el número de problemas de seguridad confirmados. Un CVE puede repetirse en varios equipos y paquetes y, aun así, representar un riesgo que merece atención. Una versión principal antigua puede estar corregida por el fabricante de la distribución. Y una clasificación crítica o alta requiere contexto antes de convertirse en una decisión operativa.
La monitorización continua de sistemas y los escáneres son herramientas imprescindibles. Su valor aumenta cuando los resultados se contrastan, se documentan sus límites y se traducen en decisiones justificadas.
En ciberseguridad, detectar es el comienzo del trabajo. El valor está en saber qué hemos encontrado, por qué importa y qué hacer al respecto.
Fuentes y alcance de la investigación
- Debian Security Tracker — CVE-2026-28417.
- Ubuntu Security — CVE-2026-28417.
- Wazuh — documentación de detección de vulnerabilidades.
- OpenSearch — agregación composite.
Fecha de corte: 14 de octubre de 2026. Los estados de las distribuciones pueden cambiar con nuevas actualizaciones de seguridad. Los resultados operativos se publican únicamente de forma agregada y anonimizada. La procedencia y los identificadores de los sistemas no se divulgan.
¿Necesitas ayuda con la tecnología de tu empresa?
Podemos revisar contigo qué está ocurriendo, qué riesgos existen y por dónde tiene sentido empezar.
