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.

 

KEV: KNOWLEDGE IS POWER

 

CNA

 

 

The term KEV, or Known Exploited Vulnerabilities Catalog, refers to a catalog maintained by the U.S. CISA (Cybersecurity and Infrastructure Security Agency) and created in collaboration with NIST (National Institute of Standards and Technology) in 2021, with the goal of providing a dynamic list of reported, actively exploited vulnerabilities. This list allows company cybersecurity leaders—whether in industrial or non-industrial domains—to know whether the vulnerabilities present in their devices can be actively exploited through an exploit, which could increase the need to remediate or mitigate those vulnerabilities.

This term is closely related to both SSVC and EPSS; however, unlike those, KEV only provides a catalog/list of actively exploited vulnerabilities, not a result or assessment of the vulnerability’s impact on a target infrastructure or device.

 

KNOWN EXPLOTED VULNERABILITIES CATALOG

In 2021, CISA, through a Binding Operational Directive in the United States, required all federal agencies to remediate vulnerabilities that affected them and that were being actively exploited.

To that end, in Directive BOD 22-01, CISA states that agencies must implement, review, and update internal vulnerability management procedures. It also sets out minimum points:

  • Establish a process for ongoing remediation of vulnerabilities that CISA identifies within an acceptable timeframe.
    • For vulnerabilities prior to the publication of KEV in 2021, agencies would have 6 months.
    • For vulnerabilities actively exploited after the publication of KEV, they would have 2 weeks.
  • Assign roles and responsibilities for executing the actions established by CISA.
  • Define the actions necessary to enable a quick response upon detection that a vulnerability is being actively exploited.
  • Create internal validation and application procedures.
  • Define requirements for tracking the directive and the list of known, actively exploited vulnerabilities (KEV).
  • Help automate and exchange vulnerability information between CISA and federal agencies.

For its part, CISA committed to

  • Provide a catalog of known, actively exploited vulnerabilities to federal organizations.
  • Keep KEV up to date and alert, based on information shared by agencies, those that may be affected.
  • Provide guidance for including and adding vulnerabilities to KEV.
  • Provide an annual report on the year’s results.

In 2022, KEV consolidated itself as a reference tool, not only for federal agencies but also for the public sector, and in 2023 it began to be adopted and incorporated by European CERTs and regulators as an official source for prioritizing vulnerability patching.

KEV Catalog

At present, the catalog contains more than 1,400 CVE that are being actively exploited. Notably, as of August 2025, of the more than 1,400 published vulnerabilities that are actively exploited—approximately 127 of the 1,405, about 9% of the total—correspond to industrial vulnerabilities.

ICS Advisory Project CISA

This compilation of vulnerabilities actively exploited in the industrial environment, as shown in the previous image, can be easily visualized in various public projects such as the CISA Known Exploited Vulnerabilities (KEV) Catalog for CISA ICS Advisories Dashboard, providing companies with a simple and visual filter of assets and organizations affected by active exploitation.

 

APPLICABILITY OF THE KEV CATALOG

Monitoring the catalog is a vital aspect of managing all vulnerabilities; specifically, monitoring actively exploited vulnerabilities will allow organizations and their cybersecurity leaders to modify patch prioritization based on the vulnerabilities that appear in the catalog.

The catalog’s emergence in 2021, together with other vulnerability management tools or frameworks such as SSVC (Stakeholder-Specific Vulnerability Categorization), complement each other perfectly—providing not only a risk result and need based on SSVC, but also an up-to-date repository (KEV) of exploitable vulnerabilities. In addition, since 2021, with the publication of the KEV catalog, vulnerability management has been able—and should be—automated in industrial environments through different tools that incorporate, classify, and automatically prioritize vulnerabilities from the KEV catalog.

But how are vulnerabilities included in the catalog? What characteristics must a vulnerability meet to be included?

  • The vulnerability must have a CVE assigned and be published in the National Vulnerability Database (NVD) of the National Institute of Standards and Technology (NIST).
  • The vulnerability must be exploitable and be actively exploited. It is not enough that the vulnerability can be exploited; it must be actively exploited to appear in the KEV catalog. CISA classifies as a vulnerability with active exploitation those for which there is evidence that malicious code execution has occurred on a real, live system with the owner’s permission (this includes exploitation attempts and successful exploits).
  • There is clear remediation guidance. CISA only adds actively exploited vulnerabilities to the catalog if there is also a mitigation or solution from the vendor. A clear example is the guidance published in 2022 on “Mitigation of attacks against uninterruptible power supply devices.”

 

PRIORITIZATION BASED ON AN EXAMPLE

To get a sense of the importance of vulnerability management based on CVEs included in the KEV catalog, let’s use the vulnerability identified as CVE-2025-41362, reported by one of our researchers in mid-2025.

For context, some technical details of the vulnerability are shown below:

  • CVE: CVE-2025-41362
  • Description: Code injection vulnerability in IDF v0.10.0-0C03-03 and ZLF v0.10.0-0C03-04. This vulnerability allows an attacker to store malicious payloads in the software that will execute in the victim’s browser. To exploit this vulnerability, it is necessary to authenticate to the device and run certain commands that can be executed with view permissions.
  • CVSS 4.0: AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
  • CVSS Score: 5.3
  • CWE: CWE-94 Improper Control of Generation of Code (‘Code Injection’)
  • CAPEC: CAPEC-70 // CAPEC-242 // CAPEC-35
  • Public Exploit: Not available.
  • Impact: Visual impact in the device’s web application, alteration of industrial processes, sending malicious requests to another industrial asset, etc.
  • Solution and mitigations: As a solution, update the device firmware or monitor activity to block potential injections as a mitigation.

 

With all this, we can review the EPSS value, which is 0.07%, implying a low risk; however, if we imagine a situation in which, for example, the device were exposed to the internet and anyone could access it, the CVSS 4.0 would change (applying environmental conditions for that specific device), the EPSS would also change, and using SSVC it would be determined that this asset must be patched as soon as possible. All of this—combined with, for example, an exploit being published and the CVE appearing in the KEV catalog—would trigger alerts in any vulnerability management tool.

All in all, at HackRTU we want to show how the specific analysis of a vulnerability in an industrial device or system is vitally important for risk management and patch prioritization. Using methodologies such as SSVC or the EPSS model, together with monitoring the KEV catalog, is very important to properly manage vulnerabilities, and industrial companies should apply these references both at a theoretical level and in practice through vulnerability-monitoring tools—because you can’t always be on top of everything. 😉

 

 

HACKRTU TEAM