Blog HackRTU

 

Aprende sobre vulnerabilidades, información técnica con una perspectiva diferente y estate a la última de todos los movimientos de HackRTU

 

Descubre los últimos artículos sobre ciberseguridad industrial, vulnerabilidades OT, análisis de dispositivos, investigaciones técnicas, 0‑days y noticias relevantes del sector. En el blog de HackRTU profundizamos en la seguridad de sistemas industriales, en la familia de estándares IEC 62443 y tendencias e investigación en el ámbito de la ciberseguridad industrial.

 

THE CVE, A KEY ELEMENT IN VULNERABILITY MANAGEMENT

 

CNA

 

A CVE or Common Vulnerabilities and Exposure is a unique and standardised identifier assigned to a publicly known vulnerability in a system, software or device.

Its objective is to establish a common and universal language to identify vulnerabilities accurately, facilitating communication to interested parties such as researchers, manufacturers, CNA (CVE Numbering Authority), CSIRT (Computer Security Incident Response Teams), PSIRTS (Product Security Incident Response Teams) or anyone interested in knowing the CVE affecting their devices or systems.

 

¿WHO MANAGES THE CVE IDENTIFIERS?

It should be noted that the NVD (National Vulnerability Database) is the US national database where CVEs are stored. All vulnerabilities in the NVD have been assigned a CVE identifier.

The National Vulnerability Database (NVD) is managed by the US National Institute of Standards and Technology (NIST), which is part of the US Department of Commerce. On the other hand, the authorised actor to manage vulnerabilities in the CVE Programme is MITRE (as the root operator of the CVE Numbering Authority or CNA). MITRE is the central coordinator, but CVE creation is decentralised across the CNA ecosystem.

 

EUVD, SIMILARITIES AND DIFFERENCES WITH THE CVE

Since 13 May 2025, the European Commission published the European Vulnerability Database (EUVD) by the European Union Agency for Cybersecurity (ENISA) to boost digital security also based on the needs imposed by the NIS2 or also called Network and Information Systems Security Directive.

The EUVD is another unique identifier like the CVE, used for the coordination and identification of vulnerabilities. Although ENISA is the actor in charge of the management of vulnerabilities with EUVD identifier, this coordination is complemented by the national CSIRTs, the European Commission (The Directorate-General for Communications Networks, Content and Technology, also called DG CONNECT), manufacturers and authorised researchers.

It is worth noting that currently, the NVD database with the different CVE identifiers that make it up is much more complete and is considered the vulnerability database par excellence. ENISA wants to promote EUVDs, but they are not yet as mature as CVEs and not all CVE identifiers exist in EUVD format, which can be confusing, although its aim is to be the reference database for vulnerabilities in Europe. Unlike CVEs, EUVD identifiers are introducing new concepts such as EPSS (Exploit Prediction Scoring System) within the data provided by the identifier or correlations with SBOMs (Software Bill of Materials).

Also, in terms of updates and new concepts, the CISA (Cybersecurity and Infrastructure Security Agency) has created a repo to conduct vulnerabilities enrichment of the CVE. This repo is a project in which CISA published the CISA's enrichment of public CVE records through CISA's ADP (Authorized Data Publisher) container. It allows the different users the capability to assessing new and recent CVEs and adding key SSVC (Stakeholder-Specific Vulnerability Categorization) decision points including parameters like the KEV (Known Exploited Vulnerabilities). 

The following table shows not only the differences between CVE and EUVD identifiers, but also the differences between the different databases and the regulatory implications of each one.

CVE vs EUVD

 

CVE IDENTIFIER STRUCTURE

Each CVE has a structured, simple format, but it contains all the necessary information to know in general terms the vulnerability's impact, its impact and usually some basic mitigations. As an example, the vulnerability CVE-2025-41360 discovered by one of our researchers will be used to explain the structure of CVEs.

  • Format: CVE-YYYYY-NNNNNN - CVE-2025-41360
    • CVE: Common prefix in all vulnerabilities.
    • YYYY-2025: year in which it is assigned or disclosed. This value may vary in many cases, as the reporting process is slow for vulnerabilities in the industrial world, so it can often take months or even several years before it is published. In the case of CVE-2025-41360, this was discovered at the end of 2021 and was assigned a different identifier than its final publication. In this case, this was due to the difference in years between the report and the publication, so the responsible CNA, INCIBE-CERT in this case, decided to update the value of the identifier.
    • NNNNN-41360: sequencial number.

 

COMPONENTS ACCOMPANYING A CVE

Although the CVE identifier itself is only a string, its publication includes several key attributes that allow it to be evaluated in depth and its criticality to be catalogued. These attributes are published by all CNA or entities in charge of CVE disclosure.

  • Technical description: A clear technical summary of the security issue involved in a vulnerability, including the context, the impact, and the conditions necessary for its exploitation in general terms without providing the exact method and taking special care in cases where the vulnerability has not been fully resolved by the manufacturer and could only be partially mitigated. Likewise, in this section, the exact version and model of the affected system, software or device is always included; if it is not included, a separate section is usually created given the relevance of the information
    • CVE-2025-41360: “Uncontrolled resource consumption vulnerability in IDF v0.10.0-0C03-03 and ZLF v0.10.0-0C03-04 from ZIV. The device is vulnerable to a packet flooding denial of service attack.”
  • CVSS (Common Vulnerability Scoring System): The CVSS provides a quantitative score of the level of severity of the vulnerability. It is based on metrics such as attack vector, complexity, required privileges, impact on confidentiality, integrity and availability. Since the latest version, CVSS 4.0, there are a greater number of environment conditions that allow a more advanced vulnerability assessment and therefore a more accurate risk value. There are now specific calculators for OT environments, which we will look at specifically in the post on CVSS.

    • CVE-2025-41360 (CVSS v4): CVSS:4.0AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N - 8,7 (High
  • CWE (Common Weakness Evaluation): The CWE in a CVE identifies the software or hardware weakness that allowed the vulnerability to be exploited. There is a list distributed by MITRE-CWE.
    • CVE-2025-41360: “CWE-400: Uncontrolled Resource Consumption”
  • Impact: Details the result of the exploitation of the vulnerability on the vulnerable system, software or device.
    • CVE-2025-41360: “Denial of the device's operational capabilities due to a Denial of Service”
  • References, mitigations o solutions: Links to security reports, vendor advisories, research publications or tools that explain or fix the vulnerability.
  • Credits: They provide the community and researchers with recognition for having detected a security flaw in the system, software or device and help manufacturers to improve their products in an ethical and responsible manner..
    • CVE-2025-41360: “INCIBE has coordinated the publication of 8 vulnerabilities: 2 of high severity and 6 of medium severity, affecting ZIV's IDF and ZLF protections. The vulnerabilities have been discovered by Aarón Flecha Menéndez from HackRTU and Gabriel Vía Echezarreta.”

On the other hand, although not strictly necessary, the following attributes or standards are also often included to provide more information about the CVE.

  • CPE (Common Platform Enumeration): the CPE precisely identifies the affected product (manufacturer, product, version, etc.). This allows both users and automated tools to correlate vulnerabilities with a list of assets.
    • CVE-2025-41360: CPE:2.3:o:zivautomation:idf0.10.0-0C08:1.1.0:*:*:*:*:*:*:*

And in the case of EUVDs, ENISA is also providing the following technical concept:

  • EPSS (Exploit Prediction Scoring System). It is a scoring system that predicts the probability of a vulnerability being exploited. Unlike the CVSS, the EPSS measures the practical probability of exploitation.

All these technical concepts accompanying the CVE make CVE identifiers more than just an identifier, but a key asset for vulnerability management and risk management of industrial companies.

In subsequent posts, it will be explained in a technical and practical way all the terms that accompany CVE identifiers based on vulnerabilities reported by our team and already published.

 

 

HACKRTU TEAM