Tag Archive for: CVE

The July 2025 Threat Report takes a broad approach, covering some of the top cyber threats from the past month. The Microsoft SharePoint flaw titles “ToolShell” dominated the headlines; see our alert on ToolShell for a detailed analysis. Over 4,000 CVEs were published last month; almost 500 of them were rated Critical, with CVSS over 9.0. Managing this volume of risk is truly a battle of attrition for defenders. In response, Greenbone published almost 5,000 new detection tests. These detection tests allow defenders to find known software flaws in their environment, confirm patch levels, and prevent cyber attackers from gaining the upper hand.

Blog Banner Threat - report July 2025

Critical Cisco ISE Flaws Offer Unauthenticated RCE as Root and More

Cisco has confirmed active exploitation of Cisco Identity Services Engine (ISE) and Cisco ISE-PIC (Passive Identity Connector) versions 3.3 and 3.4. The highest severity CVEs are: CVE-2025-20281, CVE-2025-20337, and CVE-2025-20282; all CVSS 10. CVE-2025-20281 and CVE-2025-20337 have been added to CISA KEV (catalog of known exploited vulnerabilities). Each flaw can be exploited to execute code with root privileges by submitting a malicious API request. Several national CERT agencies have issued alerts: EU-CERT, CSA Singapore, NHS UK, and NCSC Ireland. Cisco advises immediate patching; no workarounds are available. Version detection tests are included in the OPENVAS ENTERPRISE FEED [1][2][3].

Another critical severity CVE in Cisco Unified Communications Manager made waves in early July. CVE-2025-20309 (CVSS 10) allows remote root account access via static SSH credentials. Alerts were issued from Belgium’s CERT.be, NSSC Ireland, and the flaw was featured on the AUSCERT Week in Review.

CrushFTP and WingFTP Servers Under Active Attack

High severity CVEs in CrushFTP and WingFTP were published and quickly added to CISA KEV, with global CERT advisories being issued [1][2][3]. FTP servers are often exposed to the public Internet, but instances within a local network could also offer hackers an opportunity for persistence and lateral movement [4]. Also, FTP servers often store sensitive data, which could represent a high risk of being ransomed.

  • CVE-2025-54309 (CVSS 9.8, EPSS ≥ 91st pctl): If the DMZ proxy feature is not used, CrushFTP is susceptible to an unprotected alternate channel vulnerability [CWE-420]. The software mishandles AS2 validation allowing remote HTTPS admin access. The OPENVAS ENTERPRISE FEED includes a remote banner detection test to identify vulnerable instances. Users should upgrade to CrushFTP 10.8.5_12 (or later) or 11.3.4_23 (or later).
  • CVE-2025-47812 (CVSS 10, EPSS ≥ 99th pctl): Unsanitized null-byte characters in the web-interface of WingFTP prior to version 7.4.4 allow remote execution of arbitrary Lua code with the privileges of the FTP service (root or SYSTEM by default). Greenbone includes an active check and version check to identify vulnerable instances. Users are urged to update to version 7.4.4 or later.

Node.js Patch Bypass Exposes Arbitrary File Access

CVE-2025-27210 (CVSS 7.5) is a bypass for CVE-2025-23084 (CVSS 5.6), a previously patched flaw in Node.js Windows platforms, published in January 2025. An estimated 4.8% of global web servers run Node.js, which also powers many on-premises and cloud-native applications. National CERT advisories have been released warning of high risk [1][2]. At least one proof-of-concept (PoC) has been published [3]. OPENVAS ENTERPRISE FEED and COMMUNITY FEED both include a version detection check.

The flaw, classified as path traversal [CWE-22], is due to built-in functions path.join() and path.normalize() not properly filtering Windows device names like CON, PRN, and AUX, which are reserved names for special system devices [4]. This can be exploited remotely to bypass path protections when user input is passed into these functions. Node.js versions 20.x prior to 20.19.4, as well as 22.x before 22.17.1 and 24.x before 24.4.1 are affected.

CVE-2025-37099: Total Remote Compromise for HPE Insight Remote Support

New vulnerabilities in HPE Insight Remote Support pose an extreme risk of full system compromise within enterprise infrastructure. IRS is used in enterprise local network environments to automate hardware health checks, infrastructure monitoring, and support ticket generation.

CVE-2025-37099 (CVSS 9.8) permits unauthenticated remote code execution (RCE) at SYSTEM level due to improper input validation [CWE-20] in processAttachmentDataStream logic, allowing malicious payloads to be executed as code [CWE‑94][1]. This allows attackers to execute malware across managed systems. While not explicitly documented, SYSTEM-level access could also enable attackers to manipulate or delete monitoring logs to conceal activity. Since the affected service often communicates with devices like servers and iLO controllers, compromise may facilitate pivoting laterally within a network. [2]

Users should upgrade immediately to 7.15.0.646 or newer. The coordinated disclosure also included two additional CVEs; CVE-2025-37098 and CVE-2025-37097, both CVSS 7.5. OPENVAS ENTERPRISE FEED includes a version detection test to identify vulnerable instances and verify patch level to meet compliance.

Critical Patches for DELL CVEs with Elevated EPSS Scores

Cumulative patches for a wide number of Dell Technologies products were released to patch various component vulnerabilities. Canadian Cyber CSE has issued three alerts in July addressing these updates [1][2][3]. Here are some of the most critical CVEs from this batch, all of which can be detected with the OPENVAS ENTERPRISE FEED [1][2][3][4][5]:

  • CVE-2024-53677 (CVSS 9.8, EPSS 99th pctl): Dell Avamar Data Store and Avamar Virtual Edition have received updates to address a flaw in Apache Struts. No mitigations or workarounds are available. See the vendor’s advisory for affected product lists.
  • CVE-2025-24813 (CVSS 9.8, EPSS 99pctl): Dell Secure Connect Gateway versions prior to 5.30.0.14 are affected by an Apache Tomcat flaw and other critical CVEs. Dell has classified this update as critical.
  • CVE-2004-0597 (CVSS 10, EPSS 99pctl): Dell Networker is affected by critical buffer overflow flaws in libpng that allow remote attackers to execute arbitrary code via maliciously manipulated PNG images among other vulnerabilities. See vendor advisories for more information [1][2][3][4].
  • CVE-2016-2842 (CVSS 9.8, EPSS ≥ 98pctl): Dell Data Protection Advisor is affected by flaws in numerous components including CVE-2016-2842 in OpenSSL which does not properly verify memory allocation, allowing DoS or possibly RCE. See the vendor advisory for more information.
  • CVE-2025-30477 (CVSS 4.4): Dell PowerScale uses a risky cryptographic algorithm, potentially leading to information disclosure. In June 2025, PowerScale patched critical severity flaws. See vendor advisories for more information [1][2].

A Cumulative Summary of 2025 D-Link Flaws

OPENVAS ENTERPRISE FEED and COMMUNITY FEED currently include 27 vulnerability tests covering the majority of CVEs affecting D-Link products published so far in 2025. Given the importance of network edge security, users should pay particular attention to vulnerabilities in routers and other gateway devices. After the settlement of a U.S. regulatory action involving D‑Link and the Federal Trade Commission, in 2019 D‑Link agreed to implement a comprehensive security program. However, proponents for accountability may ask whether intervention should be more widespread. Ivanti products, for example, have been inundated with numerous high severity flaws in recent years [1][2][3][4][5], many leveraged in ransomware attacks.

Adobe Patches Critical Flaws for ColdFusion

Security updates for ColdFusion 2025, 2023, and 2021 address 13 new CVEs; five critical severity issues including XXE (CVE-2025-49535, CVSS 9.3), hard-coded credentials (CVE-2025-49551, CVSS 8.8), OS command injection, XML injection, and SSRF. In 2023, the ColdFusion flaw CVE‑2023‑26360 (CVSS 9.8) was used by threat actors to gain initial access to US federal civilian agencies.

OPENVAS ENTERPRISE FEED includes a remote version check to identify unpatched instances. Immediate patching to Update 3 (ColdFusion 2025), Update 15 (2023), or Update 21 (2021) is strongly recommended.

Splunk Enterprise Updates Critical Severity Components

Cumulative updates for Splunk Enterprise patch several third-party components in Splunk Enterprise including golang, postgres, aws-sdk-java, idna, and others. Some of these were Critical CVSS severity flaws such as CVE-2024-45337 (CVSS 9.1) with an EPSS percentile of ≥ 97%, indicating a high likelihood of exploit activity. CERT-FR and the Canadian Cyber CSE have published alerts related to Splunk’s July advisories. Users can verify patch status with a version check in the OPENVAS ENTERPRISE FEED. The feed also includes vulnerability checks for previous Splunk security advisories and CVEs.

Oracle Patches Row of High Severity VirtualBox Flaws

Several CVEs published in mid‑July 2025 affecting Oracle VM VirtualBox version 7.1.10 permit a high‑privileged local attacker (with access to the host infrastructure or guest VM execution environment) to compromise VirtualBox, potentially escalating privileges or achieving full control of the hypervisor core component. CVE‑2025‑53024 (CVSS 8.2) is an integer overflow bug in the VMSVGA virtual device due to insufficient validation of user‑supplied data, leading to memory corruption with potential for full hypervisor compromise. [1] OPENVAS ENTERPRISE FEED and COMMUNITY FEED include version detection tests for Windows, Linux, and macOS.

Post Authentication Flaw Allows RCE in SonicWall SMA100

CVE-2025-40599 (CVSS 9.1) is an authenticated arbitrary file upload vulnerability in SonicWall SMA 100 series appliances. It allows a remote attacker with administrative privileges to gain arbitrary code execution and persistent access. The risk posed by this flaw is increased by weak or stolen credentials. The flaw affects models SMA 210, 410, and 500v, versions 10.2.1.15-81sv and earlier. As per the vendor advisory, no workaround is effective. OPENVAS ENTERPRISE FEED includes a remote version check to identify the affected devices.

New MySQL CVEs Allow Authenticated DoS Attacks

Amidst the abundance of vulnerabilities offering unauthorized RCE, it’s easy to overlook ones that merely cause Denial of Service (DoS). A swath of DoS vulnerabilities and related patches were issued for MySQL 8 and MySQL 9 in July [1]. Although the flaws require privileged access to exploit, Managed Service Providers (MSP) may provide shared MySQL hosting for small-to-medium businesses (SMBs), government agencies, or non-profits that don’t want the overhead of managing their own database infrastructure. In this scenario, tenants are given access to separate databases on the same MySQL server instance. When that happens, an unpatched instance could allow a user to impact other organizations. These flaws also highlight the importance of strong passwords and mitigating the threat from brute-force and password spraying attacks.

Remote version detection tests are available for all CVEs referenced below. These are included in both the OPENVAS ENTERPRISE FEED and COMMUNITY FEED. Tests cover both Linux and Windows MySQL installations.

CVE ID Affected Versions Impact Access Vector Patch Status

CVE-2025-50078

(CVSS 6.5)

8.0.0–8.0.42, 8.4.0–8.4.5, 9.0.0–9.3.0 DoS (hang/crash) Remote authenticated access Patched (July 2025)

CVE-2025-50082

(CVSS 6.5)

8.0.0–8.0.42, 8.4.0–8.4.5, 9.0.0–9.3.0 DoS (crash) Remote authenticated access Patched (July 2025)

CVE-2025-50083

(CVSS 6.5)

8.0.0–8.0.42, 8.4.0–8.4.5, 9.0.0–9.3.0 DoS (crash) Remote authenticated access Patched (July 2025)

In 2025, IT security teams are overwhelmed with a deluge of new security risks. The need to prioritize vulnerability remediation is an ongoing theme among IT security and risk analysts. In a haystack of tasks, finding the needles is imperative. Factors compounding this problem include a cybersecurity talent shortage, novel attack techniques, and the increasing rate of CVE (Common Vulnerabilities and Exposures) disclosure.

To meet this need for better precision and efficiency, a wave of new prioritization metrics has emerged. Not that more perspectives on risk are a bad thing, but already overwhelmed defenders find themselves in a difficult position; the choice between pushing forward or pausing to evaluate the value of new metrics.

Released by NIST (National Institute of Standards and Technology) in May 2025, the Likely Exploited Vulnerabilities (or just LEV) metric consolidates historical EPSS (Exploit Prediction Scoring System) time-series, and in-the-wild exploitation status, to compute, among other things, an aggregate risk score. In this article, we will take a dive into what LEV is and the supplemental equations released in NIST’s recent technical whitepaper (NIST CSWP 41).

The Reason Behind LEV (Likely Exploited Vulnerabilities)

LEV uses a CVE’s historical EPSS time-series to calculate a cumulative risk score representing the probability that it has ever been actively exploited. But how is this different from EPSS itself? Isn’t EPSS, a machine learning (ML) model with almost 1,500 predictive features, good enough?

Some academic criticisms have revealed that EPSS can miss critical vulnerabilities. Direct observation of historical EPSS data shows that scores can spike for a very short period of time (1-2 days), then return to a moderate or low baseline. This presents potential problems for defenders using EPSS.

For example, EPSS does not reflect how cybercriminals operate. Industry reports show that attackers exploite vulnerabilities whenever and wherever they are found, even old ones. In other words, attackers don’t say “Let’s not exploit that vulnerability because it’s too old”. Therefore, using only the most current EPSS score can hide severe risk, even those uncovered in the recent past. Defenders may solve this problem by always applying the highest EPSS score in their risk assessment. But another weakness still looms with raw EPSS scores: According to fundamental statistical theory, the accumulation of moderate probability scores should also signify high probability of an event occurring.

LEV addresses this last limitation by calculating a cumulative probability using each CVE’s historical EPSS data. LEV applies the common product-based approach for calculating cumulative probability of at least one event occurring among several independent events. As a result, CVEs which didn’t trigger alerts (even using the max EPSS) now appear as high-risk using LEV.

Mathematical Input and Symbol Reference

This section explains the input variables and mathematical symbols used in the LEV equations.

Input Reference

  A vulnerability (e.g., a CVE) All equations
d A date (without time component) All equations
d0 First date with EPSS data for v All equations
dn The analysis date (usually today) LEV, Expected Exploited, Composite Probability
dkev Date of latest KEV (Known Exploited Vulnerabilities) list update KEV Exploited
LEV (v,d0,dn) Cumulative likelihood vulnerability v is exploited from d0 to dn All equations
EPSS (v,dn) EPSS score for vulnerability v on date dn Composite Probability
KEV (v,dn) 1.0 if v is in KEV list on dn, else 0 Composite Probability
scopedcves CVEs eligible for KEV tracking (where d0 ≤ dkev) KEV Exploited
cves CVEs considered in analysis (where d0 ≤ dn)  

Symbol Reference

Symbol Name Meaning
Universal quantifier “For all” / “For every” similar to a programming loop.
Π Capital Pi A “Product notation” for repeated multiplication over a sequence, similar to how ∑ means repeated addition.
Capital Sigma A “Cumulative notation” for repeated addition over a sequence.
Element of “Is an element of” / “belongs to”. Indicates membership in a set.

Understanding the LEV Equations

LEV is described by the “NIST Cybersecurity White Paper 41” (CSWP 41) as a lower-bound probability (conservative estimate) that a vulnerability has been exploited​. It calculates the cumulative probability that a vulnerability has been exploited at least once during a given time window. Two similar equations are provided: LEV and LEV2. The first has been optimized to reduce CPU load.

In both the LEV and LEV2 equations, each term being multiplied by the product notation Π represents the probability that no exploitation occurred on a given day within the time window. This gives the cumulative probability of no exploitation ever. Subtracting this result from 1 inverts this probability, resulting in the probability of at least one exploitation over the time window.

The two LEV equations are described below:

The Performance Optimized LEV Equation

LEV uses a CVE’s historical EPSS scores, sampled every 30 days (epss(vi, di)), along with a compensating weight when the observation window is shorter than 30 days (i.e. dn < 30 days.

The LEV equation proposed in NIST CSWP 41

The High Resolution LEV2 Equation

LEV2 uses the complete historical EPSS time-series rather than sampling scores every 30 days. LEV2 applies weighting by dividing by the duration of the EPSS window (30 days). LEV2 increases the temporal resolution and produces a more reliable score. Short bursts of high EPSS cannot be skipped over, as can happen with the LEV equation shown above. Each daily EPSS value is scaled by 1/30 to preserve consistent risk density across the date range.

The LEV2 equation proposed in NIST CSWP 41

The Supplemental Equations

This section introduces the supplemental equations from NIST’s LEV whitepaper, their mathematical structure and potential use-cases.

Calculating a Composite Risk Score

The supplemental Composite Probability metric described in NIST’s LEV whitepaper simply selects the strongest available signal across three exploitation indicators: EPSS, inclusion in CISA’s (Cybersecurity and Infrastructure Security Agency) KEV list and LEV.

The Composite Probability equation proposed in NIST CSWP 41

By selecting the strongest intelligence signal, Composite Probability supports vulnerability prioritization. This helps reduce blind spots where one signal may be incomplete or outdated. It is especially valuable for prioritizing remediation in large enterprise vulnerability management programs, where choosing what to fix first is a critical challenge.

Estimating Total Number of Exploited CVEs

NIST’s whitepaper also suggests a method to estimate the total number of exploited CVEs during a specified time window and how to estimate the comprehensiveness of a repository of known exploited vulnerabilities.

The Expected Exploited Calculation

The Expected Exploited metric estimates the number of exploited CVEs within a given time window by summing all LEV probabilities from a defined set of vulnerabilities. The equation simply applies the sum (∑) of all LEV probabilities for a set of CVEs to estimate the total number of likely events. Although the NIST CSWP 41 describes it as a lower bound (conservative) estimate, there is no precedent for treating this basic technique as such. In probability theory, it is a fundamental principle that the expected number of events is equal to the sum of the individual event probabilities.

The Expected Exploited equation proposed in NIST CSWP 41

The KEV Exploited Calculation

The KEV Exploited metric estimates how many vulnerabilities are missing from a KEV catalog such as CISA KEV. Quantifying the gap between Expected Exploited and KEV Exploited gives insight into potential underreporting of a KEV catalog. The equation uses the same technique as the Expected Exploited equation above: the sum of all probabilities.

The KEV Exploited equation proposed in NIST CSWP 41

The Revelations of LEV

Here are some ways to visualize the value that LEV can provide to a vulnerability management program. The supplemental Composite Probability equation is best for visualizing the contribution that LEV makes to a more comprehensive CVE risk analysis. Therefore, the observations below all use Composite Probability unless otherwise stated.

The Estimated Total Number of Exploited CVEs

When considering all CVEs since ~1980 (273,979), LEV’s Expected Exploited metric shows that 14.6% of all CVEs (39,925) are likely to have been actively exploited in the wild. This implies that the vast majority of exploitation activity is not accounted for in any known KEV list (e.g. CISA KEV included 1,228 at the time of calculation). However, Expected Exploited does not account for how many individual CVEs may be uncovered at various EPSS thresholds.

The Number of Uncovered High Risk CVEs

To assess how LEV may impact an organization’s ability to uncover risk and prioritize remediation, it is useful to consider how many CVEs are elevated to high risk status at various probability thresholds. The chart below shows how many CVEs would become visible above 50% Composite Probability.

 

Visualizing Risk Migration Using Composite Probability

The Sankey diagram compares the number of CVEs in each risk level. The left side shows maximum EPSS scores, while the right side shows LEV’s Composite Probability. Because Composite Probability is used, by rule, no CVEs can move to a lower probability bucket. The chart reveals a significant shift from the lowest risk bucket to higher risk categories, along with a increase for all other groups when using Composite Probability to estimate risk.

Sankey diagram showing the migration CVEs between risk buckets when using max EPSS and LEV’s Composite Probability metric

Limitations and Criticisms of LEV

While LEV offers valuable insights, it’s important to examine its assumptions and potential shortcomings:

  • The LEV whitepaper does not present empirical validation or comparisons with other statistical models. However, a frequentist approach, using product-based probability, is a well-established method for calculating cumulative probability for a set of independent events.
  • LEV is described as a lower-bound probability. However, there is no academic precedent claiming that the mathematical constructs in NIST CSWP 41 are conservative lower-bounds estimates.
  • LEV is not an opaque prediction system in itself, but it is based on EPSS, which is not a fully public model. While LEV addresses some potential blind-spots, it does depend on EPSS. As EPSS improves, LEV will also benefit from these improvements. For example, EPSS v4 has added malware activity and endpoint detections to its “ground truth” of exploitation in the wild. This will reduce bias towards remotely accessible network vulnerabilities.
  • Defenders should not over-rely on LEV, EPSS, or CVSS to prioritize vulnerabilities. While evidence of active exploitation is the strongest risk signal, this evidence often comes post-hoc – too late for defenders to leverage.

Summary

LEV may offer some enhancements to vulnerability prioritization by aggregating historical EPSS signals into a cumulative exploitation probability. This approach increases visibility for CVEs with a historical duration of moderate EPSS scores. Perhaps the most useful metric is the proposed Composite Probability, which will select the strongest signal from LEV, EPSS, and CISA KEV exploitation status.

Despite the NVD (National Vulnerability Database) outage of the NIST (National Institute of Standards and Technology), Greenbone’s detection engine remains fully operational, offering reliable, vulnerability scanning without relying on missing CVE enrichment data.

Since 1999 The MITRE Corporation’s Common Vulnerabilities and Exposures (CVE) has provided free public vulnerability intelligence by publishing and managing information about software flaws. NIST has diligently enriched these CVE reports since 2005; adding context to enhance their use for cyber risk assessment. In early 2024, the cybersecurity community was caught off guard as the NIST NVD ground to a halt. Now roughly one year later, the outage had not been fully resolved [1][2]. With an increasing number of CVE submissions each year, NIST’s struggles have left a large percentage without context such as a severity score (CVSS), affected product lists (CPE) and weakness classifications (CWE).

Recent policy shifts pushed by the Trump administration have created further uncertainty about the future of vulnerability information sharing and the many security providers that depend upon it. The FY 2025 budget for CISA includes notable reductions in specific areas such as a 49.8 million Dollar decrease in Procurement, Construction and Improvements and a 4.7 million Dollar cut in Research and Development. In response to the funding challenges, CISA has taken actions to reduce spending, including adjustments to contracts and procurement strategies.

​To be clear, there has been no outage of the CVE program yet. On April 16, the CISA issued a last minute directive to extend its contract with MITRE to ensure the operation of the CVE Program for an additional 11 months just hours before the contract was set to expire. However, nobody can predict how future events will unfold. The potential impact to intelligence sharing is alarming, perhaps signaling a new dimension to a “Cold Cyberwar” of sorts.

This article includes a brief overview of how the CVE program operates, and how Greenbone’s detection capabilities remain strong throughout the NIST NVD outage.

An Overview of the CVE Program Operations

The MITRE Corporation is a non-profit tasked with supporting US homeland security on multiple fronts including defensive research to protect critical infrastructure and cybersecurity. MITRE operates the CVE program, acting as the Primary CNA (CVE Numbering Authority) and maintaining the central infrastructure for CVE ID assignment, record publication, communication workflows among all CNAs and ADPs (Authorized Data Publishers) and program governance. MITRE provides CVE data to the public through its CVE.org website and the cvelistV5 GitHub repository, which contains all CVE Records in structured JSON format. The result has been highly efficient, standardized vulnerability reporting and seamless data sharing across the cybersecurity ecosystem.

After a vulnerability description is submitted to MITRE by a CNA, NIST has historically added:

  • CVSS (Common Vulnerability Scoring System): A severity score and detailed vector string that includes the risk context for Attack Complexity (AC), Impact to Confidentiality (C), Integrity (I), and Availability (A), as well as other factors.
  • CPE (Common Platform Enumeration): A specially formatted string that acts to identify affected products by relaying the product name, vendor, versions, and other architectural specifications.
  • CWE (Common Weakness Enumeration): A root-cause classification according to the type of software flaw involved.

CVSS allows organizations to more easily determine the degree of risk posed by a particular vulnerability and strategically conduct remediation accordingly. Also, because initial CVE reports only require a non-standardized affected product declaration, NIST’s addition of CPE allows vulnerability management platforms to conduct CPE matching as a fast, although somewhat unreliable way to determine whether a CVE exists within an organization’s infrastructure or not.

For a more detailed perspective on how the vulnerability disclosure process works and how CSAF 2.0 offers a decentralized alternative to MITRE’s CVE program, check out our article: How CSAF 2.0 Advances Automated Vulnerability Management. Next, let’s take a closer look at the NIST NVD outage and understand what makes Greenbone’s detection capabilities resilient against the NIST NVD outage.

The NIST NVD Outage: What Happened?

Starting on February 12, 2024, the NVD drastically reduced its enrichment of Common Vulnerabilities and Exposures (CVEs) with critical metadata such as CVSS, CPE and CWE product identifiers. The issue was first identified by Anchore’s VP of Security. As of May 2024, roughly 93% of CVEs added after February 12 were unenriched. By September 2024, NIST had failed to meet its self-imposed deadline; 72.4% of CVEs and 46.7% of new additions to CISA’s Known Exploited Vulnerabilities (KEVs) were still unenriched [3].

The slowdown in NVD’s enrichment process had significant repercussions for the cybersecurity community not only because enriched data is critical for defenders to effectively prioritize security threats, but also because some vulnerability scanners depend on this enriched data to implement their detection techniques.

As a cybersecurity defender, it’s worthwhile asking: was Greenbone affected by the NIST NVD outage? The short answer is no. Read on to find out why Greenbone’s detection capabilities are resilient against the NIST NVD outage.

Greenbone Detection Strong Despite the NVD Outage

Without enriched CVE data, some vulnerability management solutions become ineffective because they rely on CPE matching to determine if a vulnerability exists within an organization’s infrastructure.  However, Greenbone is resilient against the NIST NVD outage because our products do not depend on CPE matching. Greenbone’s OPENVAS vulnerability tests can be built from un-enriched CVE description. In fact, Greenbone can and does include detection for known vulnerabilities and misconfigurations that don’t even have CVEs such as CIS compliance benchmarks [4][5].

To build Vulnerability Tests (VT) Greenbone employs a dedicated team of software engineers who identify the underlying technical aspects of vulnerabilities. Greenbone does include a CVE Scanner feature capable of traditional CPE matching. However, unlike solutions that rely solely on CPE data from NIST NVD to identify vulnerabilities, Greenbone employs detection techniques that extend far beyond basic CPE matching. Therefore, Greenbone’s vulnerability detection capabilities remain robust even in the face of challenges such as the recent outage of the NIST NVD.

To achieve highly resilient, industry leading vulnerability detection, Greenbone’s OPENVAS Scanner component actively interacts with exposed network services to construct a detailed map of a target network’s attack surface. This includes identifying services that are accessible via network connections, probing them to determine products, and executing individual Vulnerability Tests (VT) for each CVE or non-CVE security flaw to actively verify whether they are present. Greenbone’s Enterprise Vulnerability Feed contains over 180,000 VTs, updated daily, to detect the latest disclosed vulnerabilities, ensuring rapid detection of the newest threats.

In addition to its active scanning capabilities, Greenbone supports agentless data collection via authenticated scans. Gathering detailed information from endpoints, Greenbone evaluates installed software packages against issued CVEs. This method provides precise vulnerability detection without depending on enriched CPE data from the NVD.

Key Takeways:

  • Independence from enriched CVE data: Greenbone’s vulnerability detection does not rely on enriched CVE data provided by NIST’s NVD, ensuring uninterrupted performance during outages. A basic description of a vulnerability allows Greenbone’s vulnerability test engineers to develop a detection module.
  • Detection beyond CPE matching: While Greenbone includes a CVE Scanner feature for CPE matching, its detection capabilities extend far beyond this basic approach, utilizing several methods that actively interact with scan targets.
  • Attack surface mapping: The OPENVAS Scanner actively interacts with exposed services to map network attack surface, identifying all network reachable services. Greenbone also performs authenticated scans to gather data directly from endpoint internals. This information is processed to identify vulnerable packages. Enriched CVE data such as CPE is not required.
  • Resilience to NVD enrichment outages: Greenbone’s detection methods remain effective even without NVD enrichment, leveraging CVE descriptions provided by CNAs to create accurate active checks and version-based vulnerability assessments.

Greenbone’s Approach is Practical, Effective and Resilient

Greenbone exemplifies the gold standard of practicality, effectiveness and resilience, achieving a benchmark that IT security teams should be striving to achieve. By leveraging active network mapping, authenticated scans and actively interacting with target infrastructure, Greenbone ensures reliable, resilient detection capabilities in diverse environments.

This higher standard enables organizations to confidently address vulnerabilities, even in complex and dynamic threat landscapes. Even in the absence of NVD enrichment, Greenbone’s detection methods remain effective. With only a general description Greenbone’s VT engineers can develop accurate active checks and product version-based vulnerability assessments.

Through a fundamentally resilient approach to vulnerability detection, Greenbone ensures reliable vulnerability management, setting itself apart in the cybersecurity landscape.

NVD / NIST / MITRE Alternatives

The MITRE issue is a wake-up call for digital sovereignty, and the EU has already (and fast) reacted. A long-awaited alternative, the EuVD by the ENISA, the European Union Agency for Cybersecurity, is there, and will be covered in one of our upcoming blog posts.

OpenVAS began in 2005 when Nessus transitioned from open source to a proprietary license. Two companies, Intevation and DN Systems adopted the existing project and began evolving and maintaining it under a GPL v2.0 license. Since then, OpenVAS has evolved into Greenbone, the most widely-used and applauded open-source vulnerability scanner and vulnerability management solution in the world. We are proud to offer Greenbone as both a free Community Edition for developers and also as a range of enterprise products featuring our Greenbone Enterprise Feed to serve the public sector and private enterprises alike.

As the “old-dog” on the block, Greenbone is hip to the marketing games that cybersecurity vendors like to play. However, our own goals remain steadfast – to share the truth about our product and industry leading vulnerability test coverage. So, when we reviewed a recent 2024 network vulnerability scanner benchmark report published by a competitor, we were a little shocked to say the least.

As the most recognized open-source vulnerability scanner, it makes sense that Greenbone was included in the competition for top dog. However, while we are honored to be part of the test, some facts made us scratch our heads. You might say we have a “bone to pick” about the results. Let’s jump into the details.

What the 2024 Benchmark Results Found

The 2024 benchmark test conducted by Pentest-Tools ranked leading vulnerability scanners according to two factors: Detection Availability (the CVEs each scanner has detection tests for) and Detection Accuracy (how effective their detection tests are).

The benchmark pitted our free Community Edition of Greenbone and the Greenbone Community Feed against the enterprise products of other vendors: Qualys, Rapid7, Tenable, Nuclei, Nmap, and Pentest-Tools’ own product. The report ranked Greenbone 5th in Detection Availability and roughly tied for 4th place in Detection Accuracy. Not bad for going up against titans of the cybersecurity industry.

The only problem is, as mentioned above, Greenbone has an enterprise product too, and when the results are recalculated using our Greenbone Enterprise Feed, the findings are starkly different – Greenbone wins hands down.

Here is What we Found

 Bar chart from the 2024 benchmark for network vulnerability scanners: Greenbone Enterprise achieves the highest values with 78% availability and 61% accuracy

 

Our Enterprise Feed Detection Availability Leads the Pack

According to our own internal findings, which can be verified using our SecInfo Portal, the Greenbone Enterprise Feed has detection tests for 129 of the 164 CVEs included in the test. This means our Enterprise product’s Detection Availability is a staggering 70.5% higher than reported, placing us heads and tails above the rest.

To be clear, the Greenbone Enterprise Feed tests aren’t something we added on after the fact. Greenbone updates both our Community and Enterprise Feeds on a daily basis and we are often the first to release vulnerability tests when a CVE is published. A review of our vulnerability test coverage shows they have been available from day one.

Our Detection Accuracy was far Underrated

And another thing. Greenbone isn’t like those other scanners. The way Greenbone is designed gives it strong industry leading advantages. For example, our scanner can be controlled via API allowing users to develop their own custom tools and control all the features of Greenbone in any way they like. Secondly, our Quality of Detection (QoD) ranking doesn’t even exist on most other vulnerability scanners.

The report author made it clear they simply used the default configuration for each scanner. However, without applying Greenbone’s QoD filter properly, the benchmark test failed to fairly assess Greenbone’s true CVE detection rate. Applying these findings Greenbone again comes out ahead of the pack, detecting an estimated 112 out of the 164 CVEs.

Summary

While we were honored that our Greenbone Community Edition ranked 5th in Detection Availability and tied for 4th in Detection Accuracy in a recently published network vulnerability scanner benchmark, these results fail to consider the true power of the Greenbone Enterprise Feed. It stands to reason that our Enterprise product should be in the running. Afterall, the benchmark included enterprise offerings from other vendors.

When recalculated using the Enterprise Feed, Greenbone’s Detection Availability leaps to 129 of the 164 CVEs on the test, 70.5% above what was reported. Also, using the default settings fails to account for Greenbone’s Quality of Detection (QoD) feature. When adjusted for these oversights, Greenbone ranks at the forefront of the competition. As the most used open-source vulnerability scanner in the world, Greenbone continues to lead in vulnerability coverage, timely publication of vulnerability tests, and truly enterprise grade features such as a flexible API architecture, advanced filtering, and Quality of Detection scores.