Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
¿Alguna vez has visto aparecer códigos «CVE-» durante la instalación de un programa y te has preguntado qué significaban? No eres el único; a todos nos ha pasado. Estos códigos son importantes señales de alarma en materia de ciberseguridad. Te guiaré a través de la anatomía de un identificador CVE, te explicaré su estructura y analizaremos conceptos como las «dependencias transitivas» y las mejores prácticas para corregir vulnerabilidades.
¿Qué es un CVE?
Antes, las vulnerabilidades tenían nombres específicos para cada fallo, como «IIS path traversal», pero a medida que se fueron acumulando a lo largo de décadas, se hizo necesario contar con un identificador estandarizado.
Un identificador de Vulnerabilidades y Exposiciones Comunes (CVE) proporciona un nombre estandarizado para las fallas de ciberseguridad identificadas y conocidas públicamente. Este lenguaje común permite a los profesionales de la seguridad y a los proveedores comunicarse de forma rápida y precisa sobre debilidades específicas. Identificar los CVE en el software es esencial —especialmente en entornos con muchos componentes externos—, ya que permite a los equipos de seguridad priorizar la aplicación de parches, evaluar el riesgo y corregir rápidamente los defectos antes de que sean explotados, protegiendo así los datos y la disponibilidad del sistema.
Puedes pensar en un CVE como un número de seguimiento, igual que cuando pides un paquete a tu tienda favorita. Es una forma de realizar un seguimiento de los errores y estar al tanto de qué versiones de un paquete se han visto afectadas por la vulnerabilidad.
Si quieres obtener una visión general completa de las mejores prácticas, puedes consultar nuestra guía detallada sobre la aplicación de parches para vulnerabilidades CVE.
La estructura de un CVE
Un CVE tiene este aspecto: «CVE-2025-1111» —el prefijo CVE, seguido del año en que se descubrió la vulnerabilidad y, a continuación, un identificador único.
Este número es asignado por MITRE Corporation y una red mundial de más de 490 CNA. Estas CNA (autoridades de numeración de CVE) incluyen proveedores de TI como Microsoft, Red Hat y Oracle, así como diversas organizaciones e investigadores de seguridad.
La Base de Datos Nacional de Vulnerabilidades (NVD) se encarga de completar cada CVE una vez que se ha publicado en la lista de CVE. En la práctica, esto significa que se produce un traspaso entre MITRE y la NVD, que a continuación completa el CVE con metadatos adicionales. Una vez completado este traspaso, se sigue un proceso concreto. Según el NIST, el proceso incluye:
- Revisar el material que se proporciona junto con el CVE.
- Un CWE (CEnumeración de debilidades comunes) ID que clasifica la vulnerabilidad.
- Se asignan métricas de explotabilidad (según los parámetros de CVSS v3.1 o v4.0) y de impacto.
- A esta vulnerabilidad se le ha asignado una declaración CPE (Common Platform Enumerator).
- Por último, un analista sénior realiza un control de calidad antes de que se publiquen los datos enriquecidos.
Una vez publicado el CVE, es posible que se realicen más tareas de mantenimiento en el futuro. Podrían introducirse modificaciones, añadirse material de referencia, actualizarse las descripciones, etc.
Comprender la vulnerabilidad
Cuando ejecutas npm audit o simplemente instalas un paquete en tu proyecto, es posible que veas un resultado como este: 7 vulnerabilidades de gravedad alta. Quizás te preguntes: «¿Qué son y cómo se ven?». El resultado inicial no muestra los CVE, sino que enumera los paquetes afectados y sus versiones. Aquí tienes un ejemplo del resultado de npm audit al instalar Angular v18 (la imagen se vuelve más confusa en versiones anteriores como Angular 16, donde la acumulación de dependencias obsoletas ha tenido más de un año para acumularse):
resumen 4.0.0 - 4.58.0 Gravedad: alta Resumen 4 tiene una vulnerabilidad de escritura arbitraria de archivos mediante recorrido de ruta - https://github.com/advisories/GHSA-mw96-cpmx-2vgc corrección disponible mediante `npm audit fix --force` Se instalará @angular-devkit/build-angular@19.2.22, lo cual supone un cambio incompatible node_modules/rollup @angular/build 18.1.0-next.0 - 19.2.21 || 20.0.0-siguiente.0 - 20.2.0-rc.1 || 20.3.4 - 20.3.17 Depende de versiones vulnerables de rollup node_modules/@angular/build @angular-devkit/build-angular * Depende de versiones vulnerables de @angular/build Depende de versiones vulnerables de copy-webpack-plugin node_modules/@angular-devkit/build-angular
Esto significa que el paquete se instaló como una dependencia transitiva. Las versiones afectadas son 4.0.0 – 4.58.0. Esas versiones presentan una vulnerabilidad de seguridad de gravedad alta. La vulnerabilidad se denomina «Arbitrary File Write via Path Traversal» (escritura arbitraria de archivos mediante recorrido de rutas). Esto significa que un actor malintencionado puede crear una entrada que engañe a Rollup para que escriba un archivo en ubicaciones en las que no tenías intención de escribir. Este es un ejemplo clásico de vulnerabilidad en la cadena de suministro de software. Instalaste un paquete, pero Rollup vino de la mano, y usted no lo instaló intencionadamente.
@angular-devkit/build-angular └── @angular/build (versiones vulnerables) └── rollup (4.0.0 - 4.58.0) ← el paquete vulnerable
Corregir defectos
Si seguimos trabajando a partir del ejemplo , hay varias formas de solucionar esta vulnerabilidad si no estás escribiendo activamente correcciones CVE como desarrollador de aplicaciones de seguridad. Podrías ejecutar npm audit fix –force, y eso podría solucionar el problema, pero ese enfoque conlleva sus propias ventajas e inconvenientes...
Si ejecutas ese comando, también actualizará @angular-devkit/build-angular a la versión 19.2.22. Esa versión está marcada como un cambio importante y podría afectar a las configuraciones de compilación y a las API. Puede que requiera cambios en el código más adelante y, ¿quién tiene tiempo para eso?
Algunas cosas que puedes hacer para ver cómo solucionarlo:
- Comprueba tu versión de Angular para evaluar qué tan grande sería el salto a la nueva versión.
- Consulte el registro de cambios de @angular-devkit/build-angular a la versión actualizada.
- Crea una nueva rama y aplica la corrección en ella, nunca en la rama principal.
- Reconoce el cambio y pospónlo si es demasiado arriesgado.
Anulaciones
El uso de una anulación es una solución temporal que puede ayudarte a seguir adelante, pero también conlleva sus riesgos. Puede obligar a utilizar una versión específica y parcheada del paquete acumulativo sin tener que recurrir a la actualización incompatible de @angular-devkit/build-angular.
Puedes añadir la versión parcheada en tu package.jsotal y como se muestra a continuación. La versión del json de ejemplo es la última versión parcheada a fecha de febrero de 2026.
{ "overrides": { "rollup": "^4.59.0" } }
Asegúrate de ejecutar npm install para instalar la versión parcheada y comprueba que se ha instalado correctamente ejecutando npm audit. Deberías ver que la vulnerabilidad ha desaparecido.
La razón por la que esta solución funciona es que el anula le dice a npm: «pase lo que pase, sin excusas, instala este paquete». Ignorará por completo el árbol de dependencias transitivas utilizando el overrides.
Las anulaciones son una buena solución cuando:
- Realmente necesitas enviar el pedido, pero la actualización te lo impide
- Dado que la vulnerabilidad se encuentra en una herramienta de compilación y no en una herramienta de producción, el riesgo es menor
- Se ha probado la versión y se ha comprobado que todo funciona correctamente
Hay mejores formas de abordar esto, ya que el sobrescrituras es solo temporal. Puedes aceptar el cambio que rompe la compatibilidad siempre y cuando lo pruebes en una rama y las pruebas salgan bien. Si no hay problemas y se ha revisado, sigue adelante. Si existe un parche y no rompe la compatibilidad, úsalo. Revisa el registro de cambios en busca de parches mayores o menores que no rompan la compilación. Una última cosa que debes hacer es evaluar el riesgo real.
Como se ha indicado anteriormente, Rollup es una herramienta de compilación, no una herramienta de producción, por lo que el riesgo es menor. Normalmente no se ejecuta en entornos de producción. El uso de las sustituciones puede crear una falsa sensación de seguridad al final del día. Dejarás de recibir advertencias de npm audit, pero también estarás introduciendo cambios sin probar en tu proyecto o compilación.
La conclusión es sencilla: si puedes aceptar el cambio que rompe la compatibilidad, hazlo. Si no puedes, utiliza las sustituciones.
