CVE, EPSS y CISA KEV: inteligencia de vulnerabilidades con IA desde la terminal

Todo el contenido publicado aquí —artículos, scripts, herramientas y configuraciones— tiene fines exclusivamente educativos y refleja mi experiencia personal trabajando sobre infraestructura propia o en entornos de laboratorio controlados.

Las técnicas, metodologías y herramientas descritas están pensadas para su uso en sistemas propios o con autorización explícita de sus propietarios. El conocimiento de técnicas ofensivas forma parte del aprendizaje defensivo; publicar algo no implica que sea adecuado para cualquier contexto.

Si reutilizas o adaptas lo que encuentres aquí, eres responsable de hacerlo dentro del marco legal de tu país, especialmente en materia de protección de datos (RGPD), acceso no autorizado a sistemas (art. 197 bis CP) y privacidad. El autor no asume responsabilidad por usos que contravengan la legislación aplicable.

Este contenido está dirigido a un público técnico con criterio propio. Úsalo con cabeza.

Sun Tzu lo dejó escrito hace 2.500 años: conoce al enemigo y conócete a ti mismo.

El problema es que en seguridad tendemos a obsesionarnos con el primero y saltarnos el segundo. Escaneamos redes, analizamos vulnerabilidades, buscamos CVEs —y en ningún momento nos preguntamos si las herramientas que usamos para hacer eso son de fiar.

Eso es lo que hice diferente esta vez.

Antes de poner en marcha un servidor MCP con 27 herramientas de inteligencia de vulnerabilidades, hice una auditoría completa del código. Cuatro análisis paralelos. Treinta y cuatro hallazgos clasificados por severidad. Y la conclusión fue que el código es apto —pero por razones que no son evidentes a simple vista.

Esto es lo que encontré, lo que apliqué como mitigación, y cómo encaja en un flujo real de pentesting.

Índice

• Qué hace este servidor MCP
• Las 27 herramientas por categoría
• Auditoría de seguridad previa
• La instalación
• El scoring que más me interesa: EPSS
• El problema de priorizar solo por CVSS
• Flow en una auditoría de pentest
• Un caso real: CVE-2024-21413
• APIs gratuitas vs de pago

Qué hace este servidor MCP

cve-mcp-server es un servidor MCP open source que conecta con 21 APIs de seguridad:

• NVD (National Vulnerability Database) — datos oficiales de CVEs
• EPSS (Exploit Prediction Scoring System) — probabilidad de explotación
• CISA KEV — catálogo de vulnerabilidades explotadas activamente
• MITRE ATT&CK — técnicas de ataque reales
• GitHub Search — PoCs públicos
• VirusTotal, MalwareBazaar, ThreatFox — threat intelligence
• Shodan, AbuseIPDB, GreyNoise — inteligencia de red

En total, 27 herramientas que tu asistente puede usar directamente desde una conversación.

Consulta de CVEs

• lookup_cve — datos NVD oficiales: CVSS, descripción, referencias
• search_cves — búsqueda por producto, keyword o severidad
• get_cve_summary — resumen ejecutivo listo para reportar
• get_cve_timeline — línea de tiempo: publicación → PoC → KEV → parche
• parse_cvss — desglose del vector CVSS en componentes
• compare_cves — comparar varios CVEs en paralelo

Priorización y scoring

• get_epss_score — probabilidad de explotación en los próximos 30 días
• check_kev — ¿está en el catálogo CISA KEV?
• calculate_risk_score — score compuesto 0-100 (CVSS + EPSS + KEV + PoC)
• check_exploit_availability — ¿hay exploit en ExploitDB o Metasploit?
• check_poc_exists — ¿hay PoC público en GitHub?

MITRE ATT&CK y contexto

• get_attack_mapping — técnica y táctica ATT&CK asociada al CVE
• get_vendor_advisory — aviso oficial del fabricante (MSRC, Cisco, etc.)

Threat intelligence

• check_ip_reputation — reputación vía AbuseIPDB y GreyNoise
• get_domain_intel — inteligencia de dominio: categoría, riesgo, registros
• passive_dns_lookup — historial DNS pasivo de IP o dominio
• check_url_safety — análisis de URL contra VirusTotal
• lookup_file_hash — hash en MalwareBazaar: familia, firma, campañas
• lookup_malware_family — IOC en ThreatFox: tipo, confianza, C2
• check_ransomware_intel — dirección Bitcoin asociada a ransomware
• shodan_host_lookup — puertos abiertos, banners y CVEs (requiere API key)

Dependencias y código

• check_package_vulns — CVEs en un paquete concreto vía OSV.dev
• scan_dependencies — escanear una lista de dependencias de golpe
• scan_container_packages — CVEs en paquetes de una imagen de contenedor
• scan_repo_secrets — secretos expuestos en repositorios públicos

Reporting

• generate_vuln_report — informe ejecutivo listo para entregar
• health_check — estado de las APIs y caché local

Auditoría de seguridad previa a la instalación

Antes de instalar nada, hice una auditoría de seguridad exhaustiva del código. Cuatro análisis paralelos sobre todos los ficheros Python, configuración y CI/CD.

Lo que encontré:

¿Significa que el código es malo? No necesariamente. El contexto importa.

La mayoría de los hallazgos críticos son SSRF e inyecciones que solo son explotables si un usuario no confiable controla los inputs. En un entorno local vía stdio, donde solo tú controlas los inputs, el riesgo real es bajo.

Lo que sí apliqué como mitigación:

1. Versiones fijadas — generé un fichero de dependencias con los 43 paquetes a versión exacta. Sin esto, una versión futura de cualquier dependencia podría ser maliciosa.
2. Sin API keys innecesarias — empecé solo con las APIs gratuitas que no requieren credencial.
3. Fichero .env con permisos 600 — la configuración solo la lee el usuario propietario.

Lo positivo que encontré:

• Usa defusedxml para XML (mitiga XXE)
• verify=True en todas las peticiones HTTPS
• Bloqueo RFC 1918 implementado (no hace peticiones a IPs privadas)
• Rate limiter para NVD
• Caché SQLite con TTLs diferenciados por recurso

Sin backdoors. Sin código malicioso. Apto para uso local con las precauciones mencionadas.

La instalación

# Entorno dedicado Python 3.12
conda create -n mcp-cve python=3.12 -y

# Instalar desde el repo clonado
cd ~/cve-mcp-server
pip install -e .

# Fijar versiones (supply chain mitigation)
pip freeze > requirements-pinned.txt

Registro en ~/.claude.json:

"cve-mcp": {
    "command": "/path/to/envs/mcp-cve/bin/cve-mcp",
    "args": [],
    "env": {
        "ENV_FILE": "/path/to/cve-mcp-server/.env"
    }
}

En el primer arranque, el servidor descarga el catálogo CISA KEV completo (1.614 entradas en el momento de escribir esto).

El scoring que más me interesa: EPSS

El CVSS clásico (la escala 0-10 que todo el mundo conoce) tiene un problema: mide la severidad teórica de una vulnerabilidad, no la probabilidad de que alguien la explote en la práctica.

Un CVE puede ser 9.8 en CVSS y llevar 3 años sin que nadie lo explote. Otro puede ser 6.5 y estar siendo explotado masivamente esta semana.

EPSS (Exploit Prediction Scoring System) intenta resolver esto: es la probabilidad (0.0–1.0) de que un CVE sea explotado en los próximos 30 días, calculada con datos reales de telemetría.

El servidor usa una fórmula compuesta:

Score = (CVSS × 0.20) + (EPSS × 0.35) + (KEV × 0.30) + (PoC × 0.15)

El peso más alto no es el CVSS sino el EPSS (35%) seguido del CISA KEV (30%). Si una vulnerabilidad está en el catálogo KEV de CISA, significa que ya está siendo explotada activamente en campo. Eso vale más que el score teórico.

El problema de priorizar solo por CVSS

Dos CVEs reales, ambos con CVSS 9.8. El mismo score teórico. Decisiones completamente distintas.

CVE-2022-1471 — SnakeYAML (deserialización Java)

En teoría, una deserialización Java sin restricciones es devastadora. En la práctica, explotar CVE-2022-1471 requiere que el atacante controle el YAML que parsea la aplicación —lo que en la mayoría de implementaciones reales significa ficheros de configuración locales, no inputs externos. Lleva dos años en la naturaleza. Nadie lo explota activamente.

CVE-2024-21413 — Microsoft Outlook (Moniker Link)

Mismo CVSS. Diferente realidad: explotación sin interacción del usuario, en campo desde el día siguiente a la publicación, con PoCs listos para descargar.

Si priorizas por CVSS, los dos entran en la misma lista de “críticos urgentes”. Si priorizas por score compuesto, uno puede esperar a la próxima ventana de parches. El otro no puede esperar ni 24 horas.

Esa diferencia es la que hace útil el EPSS.

Flow en una auditoría de pentest

Así encaja este MCP en el workflow de pentesting:

pentest_scan → versión de servicio detectada
    ↓
lookup_cve → ¿tiene CVE conocido?
    ↓
get_epss_score → ¿probabilidad de explotación?
    ↓
check_cisa_kev → ¿explotado activamente?
    ↓
search_github_pocs → ¿hay PoC público?
    ↓
calculate_composite_risk → score 0-100
    ↓
map_to_attack → técnica MITRE ATT&CK
    ↓
pentest_report → documentar ANTES de explotar

El último paso no es opcional: documentar y preguntar antes de explotar cualquier vulnerabilidad. Este MCP aporta el contexto para tomar esa decisión con datos reales en lugar de intuición.

Un caso real: CVE-2024-21413

Esto es lo que ocurre en la práctica. Un escáner detecta una versión de Microsoft Outlook en un sistema durante una auditoría. La primera pregunta es si esa versión tiene CVEs conocidos con explotación activa.

lookup_cve CVE-2024-21413

{
  "cve_id": "CVE-2024-21413",
  "description": "Microsoft Outlook Remote Code Execution Vulnerability",
  "cvss_score": 9.8,
  "cvss_severity": "CRITICAL",
  "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
  "published": "2024-02-13"
}

CVSS 9.8, crítico. Pero el CVSS es solo el punto de partida. Lo siguiente es saber si alguien lo está explotando realmente.

get_epss_score CVE-2024-21413

{
  "cve": "CVE-2024-21413",
  "epss": 0.9412,
  "percentile": 99.8
}

EPSS 0.94. Percentil 99.8 entre todos los CVEs conocidos. No es teórico: el 94% de probabilidad de explotación en los próximos 30 días es una señal de que ya está siendo usado activamente.

check_cisa_kev CVE-2024-21413

{
  "in_kev": true,
  "product": "Microsoft Outlook",
  "date_added": "2024-02-14",
  "notes": "Apply mitigations per vendor instructions."
}

En el catálogo KEV. CISA lo confirmó al día siguiente de la publicación del CVE. Eso significa explotación activa en infraestructuras reales, no en laboratorios.

search_github_pocs CVE-2024-21413

{
  "pocs_found": 4,
  "repos": [
    {"name": "xaitax/CVE-2024-21413", "stars": 412},
    {"name": "duy-31/CVE-2024-21413",  "stars": 89}
  ]
}

Cuatro PoCs públicos. El más popular con 412 estrellas. Cualquiera puede descargarlo y ejecutarlo en cinco minutos.

Con todos los datos, el score compuesto:

calculate_composite_risk CVE-2024-21413

{
  "composite_score": 97,
  "breakdown": {
    "cvss_contribution":  19.6,
    "epss_contribution":  32.9,
    "kev_contribution":   30.0,
    "poc_contribution":   15.0
  },
  "priority": "CRÍTICO — acción inmediata"
}

97 sobre 100. El CVSS aporta 19.6 de los 97 puntos. Si hubiéramos priorizado solo por CVSS, este CVE habría entrado en la misma lista que decenas de vulnerabilidades críticas que llevan años sin explotarse. El EPSS y el KEV son los que lo separan del resto.

Por último, la técnica de ataque asociada:

map_to_attack CVE-2024-21413

{
  "techniques": [
    {"id": "T1566.001", "name": "Spearphishing Attachment", "tactic": "Initial Access"},
    {"id": "T1203",     "name": "Exploitation for Client Execution", "tactic": "Execution"}
  ]
}

El vector es phishing dirigido. Outlook procesa el enlace Moniker antes de que el usuario haga clic. Sin interacción del usuario, ejecución remota de código.

Todo esto, desde el terminal, en menos de dos minutos.

APIs gratuitas vs de pago

La mayoría de lo útil es gratuito:

Lo de pago que añadiría cuando haga auditorías externas reales:

• Shodan (49$ único) — para ver qué está expuesto en internet
• NVD API key (gratuita, registro) — si se hacen muchas consultas

Conclusión

La filosofía que sigo con cada herramienta nueva es la misma: probarla primero en casa, entender sus limitaciones, y contar los resultados.

El servidor está instalado, auditado y funciona. Las 1.614 entradas de CISA KEV ya están en caché local. La próxima vez que el escáner detecte una versión vulnerable de algo en mi red, tendré contexto real para decidir qué hacer con ello.

El código tiene cosas mejorables. Las he documentado. Y el proyecto sigue activo — si las fixes llegan upstream, las incorporamos.

¿Tienes un stack de seguridad en tu homelab? ¿Qué fuentes de inteligencia de vulnerabilidades usas?