# La avalancha de CVE del kernel Linux: cómo trabaja su CNA y por qué hay más de 18.000

- **Publicado el:** 2026-11-10
- **Categoría:** Seguridad
- **Página original:** https://linuxgratis.com/articulos/cve-kernel-linux-avalancha-cna

Desde febrero de 2024 el propio kernel Linux asigna sus CVE y le pone uno a casi cada corrección que llega a un kernel estable. Contamos los registros de su repositorio vulns: 4.287 en 2024, 5.675 en 2025 y 8.228 en lo que va de 2026. Qué significa para las distribuciones y cómo gestionarlo sin revisar CVE a CVE.

---

Quien vigile las alertas de seguridad de un servidor Linux lo habrá notado: cada semana aparecen decenas de CVE nuevos del kernel, muchos con descripciones que parecen simples correcciones de errores. No es una impresión. Desde que el proyecto se convirtió en **CVE Numbering Authority (CNA)** en febrero de 2024, el equipo que asigna los identificadores aplica una política deliberadamente amplia, y los números se han disparado.

## Por qué el kernel se hizo CNA

Una CNA es una organización autorizada por el programa CVE para asignar identificadores a las vulnerabilidades de su ámbito. Antes de 2024, cualquier CNA externa (una empresa, un investigador a través de MITRE) podía registrar un CVE contra el kernel sin pasar por sus desarrolladores. La documentación oficial del proceso, `Documentation/process/cve.rst`, lo explica sin rodeos: los CVE del kernel «se asignaban muy a menudo de forma inapropiada y por razones inapropiadas», y los «abusos de individuos y empresas ajenos a la comunidad» dejaron claro que el control de esas asignaciones debía estar en manos del propio proyecto.

**Greg Kroah-Hartman**, responsable de las ramas estables, lo anunció en su blog el **13 de febrero de 2024** con la entrada «Linux is a CNA». Ahí reconoce que considera el sistema CVE «roto en muchos aspectos», pero ve el cambio como una forma de asumir responsabilidad y prepararse para las leyes que empiezan a exigir a los proyectos de código abierto que gestionen sus vulnerabilidades. Cita a curl y Python como proyectos que dieron el mismo paso por las mismas razones.

Desde entonces, la documentación establece que un CVE asignado por otra organización a una versión soportada del kernel **no debe considerarse válido**, y que solo los mantenedores del subsistema afectado pueden disputar o modificar uno.

## Un CVE para casi cada corrección

La clave está en un párrafo de `cve.rst`. Por la posición del kernel en el sistema, «casi cualquier fallo podría explotarse para comprometer su seguridad», pero esa posibilidad rara vez es evidente cuando se corrige. Por eso el equipo es «excesivamente cauto» y asigna un CVE **a cualquier corrección que identifique**. La propia documentación admite que esto explica «el número aparentemente grande de CVE» que emite.

Hay otras reglas que conviene conocer:

- Los CVE se asignan **solo cuando la corrección ya está en un kernel estable**, y se identifican por el *commit* original. Nada de CVE para fallos sin parche, salvo que alguien pida uno reservado escribiendo a `cve@kernel.org`.
- No se asignan CVE a versiones que ya no mantiene el equipo de estables y LTS. Hoy son la 7.3 y las *longterm* 6.18, 6.12, 6.6, 6.1, 5.15 y 5.10, según [kernel.org](https://www.kernel.org/releases.html).
- Los fallos que solo existen en el kernel parcheado de una distribución corresponden a esa distribución, no al CNA del kernel.
- Decidir si un CVE afecta a un sistema concreto **es cosa de quien lo usa**. El texto lo dice así: «no conocemos tu caso de uso ni qué partes del kernel utilizas».

Cada asignación se publica en la lista **linux-cve-announce** y queda registrada en el repositorio `vulns.git` de kernel.org.

## Los números, contados en el repositorio

El repositorio guarda un directorio por CVE publicado en `cve/published/`, con el registro JSON, el aviso enviado a la lista y el fichero `.dyad`, que indica en qué versiones apareció el fallo y en cuáles se corrigió. Contando cuándo entró cada registro en el historial de git (datos a 2 de noviembre de 2026, solo los que siguen publicados):

| Año | CVE publicados |
|---|---|
| 2024 (desde febrero) | 4.287 |
| 2025 | 5.675 |
| 2026 (hasta el 2 de noviembre) | 8.228 |
| **Total** | **18.190** |

Otros 324 se han rechazado después de asignarse. El ritmo de 2026 casi dobla al del año anterior, con agosto (1.643) y septiembre (2.112) como los meses más intensos de la serie; el repositorio no explica el motivo del salto. Si se cuenta por el año del identificador en lugar de por la fecha de publicación, salen 3.064 CVE-2024, 2.667 CVE-2025 y 7.971 CVE-2026, más 4.488 con identificadores de 2019 a 2023 que corresponden a correcciones antiguas catalogadas a posteriori, sobre todo en 2024.

## Las críticas y el efecto en las distribuciones

El problema práctico es evidente: muchas herramientas de cumplimiento y escáneres de vulnerabilidades tratan cada CVE como algo que hay que revisar, documentar y cerrar. Con cientos de avisos al mes, un equipo de seguridad de empresa no puede analizar uno por uno, y las distribuciones con kernels de soporte largo tienen que decidir cuáles afectan a sus versiones y cuáles no. Durante mucho tiempo los registros del CNA tampoco llevaban puntuación de gravedad, lo que obligaba a cada distribución a calcular la suya.

Eso último ha cambiado en parte: desde **abril de 2026** el repositorio incluye una herramienta para asignar puntuaciones **CVSS 3.1**, y 6.562 CVE publicados ya tienen su fichero `.cvss` con la justificación de cada métrica.

La postura del equipo del kernel no ha cambiado: lo recomendable es aplicar **todas** las correcciones de una versión estable, porque se prueban juntas, y no escoger parches sueltos. La documentación añade que algunas correcciones relevantes pueden no tener CVE, porque el equipo no siempre las detecta.

## Cómo gestionarlo como administrador

- **Sigue el kernel estable o LTS de tu distribución** y actualiza con su ritmo. Es lo que propone el propio kernel: tomar la versión completa en vez de evaluar CVE a CVE. Los boletines de la distribución, como los [USN del kernel de Ubuntu](/articulos/usn-8059-kernel-linux-febrero-ubuntu), ya hacen ese filtrado por ti.
- **Reserva el análisis individual para lo que importa**: fallos con explotación pública o que tocan componentes que realmente usas. Casos como [Copy Fail](/articulos/cve-2026-31431-copy-fail-algif-aead-privesc-root-kernel-linux) o [Dirty Frag](/articulos/dirty-frag-kernel-linux-escalada-privilegios-mitigacion) sí merecen atención inmediata y, a veces, una mitigación temporal.
- **Usa las herramientas del repositorio `vulns.git`**. `bippy` es la que genera los registros JSON y los avisos, y `dyad` calcula los pares de versión vulnerable y corregida a partir de un *commit*; son más útiles para entender cada registro que para el día a día. Para comprobar una versión concreta resulta más práctico `strak`, que lista los CVE que siguen sin corregir en un *commit* o versión dada, y `cve_search`, que relaciona un *commit* con su CVE y al revés. Todas necesitan un clon local del árbol estable del kernel.
- **Desactiva lo que no uses**. Muchos CVE afectan a controladores o protocolos que en un servidor nunca se cargan; poner en lista negra esos módulos reduce de verdad la superficie de ataque.

Las versiones mantenidas del kernel y sus fechas están en la [ficha de Linux](/linux-kernel).

**Fuentes:** [Documentation/process/cve.rst](https://docs.kernel.org/process/cve.html); [repositorio vulns.git](https://git.kernel.org/pub/scm/linux/security/vulns.git/) del CNA del kernel (recuento propio a 2-nov-2026); [archivo de linux-cve-announce](https://lore.kernel.org/linux-cve-announce/); [«Linux is a CNA»](http://www.kroah.com/log/blog/2024/02/13/linux-is-a-cna/), de Greg Kroah-Hartman; [versiones mantenidas en kernel.org](https://www.kernel.org/releases.html).