Blog HackRTU

‹ Regresar

CPE, EL PASAPORTE DE LOS DISPOSITIVOS VULNERABLES

 

CNA

 

 

Common Platform Enumeration or CPE is a readable standard naming scheme for encoding computer systems, software and packages. Based on the generic syntax of Uniform Resource Identifiers (URIs), CPEs include a formal name format, a method for checking names of a system, and a description format for linking text and evidence to a name.

In short, the CPE provide a dictionary of common computer systems, platforms and packages encoded in a standardised naming format and suitable for interpretation and processing.

It was originally developed by MITRE in the mid-2000s, but since 2013, the ownership and operation of the CPE was transferred to the NIST (National Institute of Standards and Technology) as part of the U.S National Vulnerability Database (NVD).

 

HISTORY OF THE CPE

Although MITRE transferred the ownership of the CPE and its operation to NIST in 2013, several earlier versions already existed. In 2005, MITRE published the first draft, the CPE version 0.9, to assess the feasibility of the standard (this version is currently not available in the official repository).

The CPE 1.1 version, published in March 2007, was the first to appear officially in the MITRE repositories. This version established a basic XML syntax for describing product names and served as a starting point for future versions.

 

Subsequently, the CPE 2.0 version at the end of 2007 introduced a fundamental change, separating the specifications contained in the CPE into different modules (dictionary schema, expression language, validation schemas, etc.). The CPE 2.1 version was published on 31 January 2008 by MITRE, representing a major step forward in both formalisation and relevance in the sector. The CPE 2.2 version, similar to the previous version, was released in 2009, and introduced a new reference implementation, a Java code from which information could be easily extracted using automated security tools.

Finally, NIST published the CPE 2.3 version in August 2011. This version is the version currently used during vulnerability management, although NIST continues to support the dictionary based on CPE 2.2 through its CPE browser.

 

CPE 2.3, THE LATEST VERSION PUBLISHED

Since its publication in mid-2011, the new version of the standard is the most widely used due to its new implementations and improvements in terms of separation into different independent specifications: ‘Naming Specification’, ‘Dictionary Specification’, ‘Applicability Language Specification’ and ‘Matching Specification’.

Version 2.3 defines a uniform string format, specifications for its use and matching rules to identify cross-platform equivalences. In addition, unlike previous versions, it provides a fully human- and machine-readable structure, further facilitating integration into vulnerability detection tools based on inventoried assets, by manufacturer, operating system, firmware versions, target devices, etc.

The CPE 2.3 version is based on the four specifications mentioned above, which we will now briefly break down:

• Naming Specification: This section indicates how a CPE should be written, the order of the features, format up to a maximum of 13 values starting with CPE, the version of the standard used and then the product concerned (with multiple features):
  • wfn:[part="o",vendor="ziv",product="idf",version="0.10.0-0C03-03 ",update="beta"]
  • This naming method is known as well-formed CPE (WFN). Subsequently, the specification itself also defines how to transform the above string into a Uniform Resource Identifier link:cpe:/o:zivautomation:idf: 0.10.0-0C03-03:beta
  • Likewise, also, within the specification, the so-called formatted string, similar to the previous string, but with complementary characteristics to the base, is admitted and contemplated:
  • cpe:2.3:o:zivautomationidf: 0.10.0-0C03-03 beta:*:*:*:*:*:*

 

• Dictionary Specification: This refers to a record or listing of all valid products, i.e. it is like a dictionary with all possible valid combinations of unique CPE. Each entry in these ‘dictionaries’ has its CPE identifier, the date of publication, a title, external references, etc. In these dictionaries, only WFNs that identify a single product class are stored, not a set of product classes:
  • wfn:[part="o",vendor="zivautomation",product="idf",version="0.10.0-0C03-03 ", update="NA",edition=NA,language=NA,sw_edition="NA", target_sw=NA,target_hw="NA",other=NA]
  • As mentioned above, there are several dictionaries, but the official CPE dictionary is managed by NIST and is the authoritative repository of CPE names allowing any person, organisation or automated tool to find the names of identifiers in a centralised location.
• Applicability Language: Allows to know which exact version of the product is affected by the vulnerability. Defines a standardised way of describing the affected platforms by forming complex logical expressions.
• Matching Specificación: This specification defines the method to perform a one-to-one comparison of a source CPE name with a target CPE name. That is, it allows verifying whether a particular product is installed on a system. This allows asset management tools that have collected information to compare its characteristics with a WFN string to find out if the deployed asset is the same one that may have vulnerabilities in a fast and efficient way. An example of the WFN within this specification would be:
  • wfn:[part="o",vendor="zivautomation",product="idf", versión="0.10.0-0C03-03 ",actualización=NA,edición=NA,idioma="en\-us"]

Although in general terms the CPE specifications and the CPE identifier may seem complex, they simplify many processes such as the quick detection of vulnerabilities based on deployed systems or on the basis of components used in an industrial system. A clear example, within a SBOM (Software Bill of Materials) with version information would allow, thanks to the CPE, to detect by means of an automated tool quickly and efficiently which CVE affects that component, asset or system.

 

CPE 2.3 EXAMPLE

In this case, and to give a context of the different fields that the CPE has, we will use the vulnerability CVE-2025-41362, with a CVSS 4.0 of 5.3 detected by one of our researchers.

Before looking at the CPE (it does not yet exist in the CPE database), to give context, the vulnerability associated with this CPE is a code injection in both IDF v0.10.0-0C03-03 and ZLF v0.10.0-0C03-04 and with CWE-94 (Code Injection) which would allow an attacker to store a malicious payload in the software and then execute it in the victim's browser. This vulnerability was discovered during the analysis of the device (more information about the service here) in a lab environment.

Although the CVE ID was published on 6 June 2025, as of the date of publication of this post, 7 July 2025, there is still no CPE for the product and version (IDF v0.10.0-0C03-03 and ZLF v0.10.0-0C03-04 from ZIV Automation) affected by the vulnerability.

In this blog post, we will simulate what could be the official CPE published by NIST and explain each of the fields for the IDF product with version v0.10.0-0C03-03:

CPE:2.3:o:zivautomation:idf_firmware:0.10.0-0C08:1.1.0:*:*:*:*:*:*:*

• CPE: First string value indicating that a reference is made to an FPC identifier.
  • 2.3: Version of the standard used, in this case the latest available and published by NIST.
  • o: Refers to the type of product affected, there are 3 possibilities: Application (a), operating system (o) or hardware (h). In this case, and given that information on the operating system is available, the o is used.
  • zivautomation: Section of the manufacturer or supplier that has been affected, in this case ZIVAUTOMATION instead of ZIV, given that when looking for other vulnerabilities of the manufacturer itself, there were CPEs already associated with the manufacturer ZIVAUTOMATION in the dictionary.
  • idf_firmware: Model of the affected device and within the dictionary of CPE.
  • 0.10.0-0C08:1.1.0: Version of the affected product, in this case, extracting information from the CVE, we have that the affected version of the IDF is 0.10.0-0C08:1.1.0.

The rest of the fields of the CPE in this case, are marked as *, which refers to any possibility, but, below, we show what the remaining fields would refer to following the order established by MITRE and the specifications.:

• Update: Device update or patch.
• Edition: Remaining field from version 2.2. It is now in almost all cases displayed as * or - as this field is now broken down into sw_edition, target_sw, target_hw, language, others.
• Language: Language of the product concerned (es, en, pt, etc.).
• Sw_edition: Software version (Example: professional, referring to Siemens SIMATIC WinCC Professional version).
• Target_sw: CPE target platform (Examples: vxworks, unix, aix, etc.).
• Target_hw: Target affected hardware (Examples: s7-1500, rx3i, cibtrikkigux-5580, etc.).
• Other: Field reserved for other relevant characteristics.

 

At HackRTU, we believe that the use of standards such as CPE is essential to accurately and automatically manage the risks associated with vulnerabilities, especially in industrial environments. In addition, based on new regulations and directives such as NIS2 and CRA, the use of CPE can greatly facilitate organisations' vulnerability management based on their inventories or specific SBOMs for the automation of CVE review based on CPE.

 

 

HACKRTU TEAM