Tag Archive for: CVE

Joseph Lee

LEV: Demystifying the New Vulnerability Metrics in NIST CSWP 41

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.

Contact Test Now Buy Here Back to Overview

/by
Joseph Lee

March 2025 Threat Report: Who Do You Trust?

When it comes to protecting your organization from digital threats, who should you trust? Reality dictates that high-resilience IT security is forged from a network of strong partnerships, defense in depth; layered security controls, and regular auditing. Defensive posture needs to be monitored, measured and continuously improved. While vulnerability management has always been a core security control, it is nonetheless a fast moving target. In 2025, continuous and prioritized mitigation of security threats can have a big impact on security outcomes as adversarial time-to-exploit diminishes.

In March 2025’s monthly Threat Report, we will highlight the importance of vulnerability management and Greenbone’s industry leading vulnerability detection by reviewing the most recent critical threats. But these new threats only scratch the surface. In March 2025, Greenbone added 5,283 new vulnerability tests to our Enterprise Feed. Let’s jump into some of the important insights from a highly active threat landscape.

The US Treasury Breach: How Did It Happen?

In late December 2024, the U.S. Treasury Department disclosed that its network was breached by Chinese state-backed hackers and subsequently leveraged sanctions in early January 2025. Forensic investigations have tracked the root-cause to a stolen BeyondTrust API key. The vendor has acknowledged 17 other customers breached by this flaw. Deeper investigation has revealed that the API key was stolen via a flaw in a PostgreSQL built-in function for escaping untrusted input.

When invalid two-byte UTF-8 characters are submitted to a vulnerable PostgreSQL function, only the first byte is escaped, allowing a single quote to pass through unsanitized which can be leveraged to trigger an SQL Injection [CWE-89] attack. The exploitable functions are PQescapeLiteral(), PQescapeIdentifier(), PQescapeString() und PQescapeStringConn(). All versions of PostgreSQL before 17.3, 16.7, 15.11, 14.16, and 13.19 are affected as well as numerous products that depend on these functions.

CVE-2024-12356, (CVSS 9.8) and CVE-2024-12686, (CVSS 7.2) have been issued for BeyondTrust Privileged Remote Access (PRA) and Remote Support (RS) and CVE-2025-1094 (CVSS 8.1) addresses the flaw in PostgreSQL. The issue is the subject of several national CERT advisories including Germany’s BSI Cert-Bund (WID-SEC-2024-3726) and the Canadian Centre for Cybersecurity (AV25-084). The flaw has been added to CISA’s known exploited vulnerabilities (KEV) list, and a Metasploit module that exploits vulnerable BeyondTrust products is available, increasing the risk. Greenbone is able to detect the CVEs (Common Vulnerabilities and Exposures) discussed above both in BeyondTrust products or instances of PostgreSQL vulnerable to CVE-2025-1094.

Advanced fined 3.1 Million Pound for Lack of Technical Controls

This month, the UK’s Information Commissioner’s Office (ICO) imposed a 3.07 million Pound fine on Advanced Computer Software Group Ltd. under the UK GDPR for security failures. The case is evidence of how the financial damage caused by a ransomware attack can be further exacerbated by regulatory fines. The initial proposed amount was even higher at 6.09 million Pound. However, since the victim exhibited post-incident cooperation with the NCSC (National Cyber Security Centre), NCA (National Crime Agency) and NHS (National Health Service), a voluntary settlement of 3,076,320 Pound was approved. While operational costs and extortion payments have not been publicly disclosed, they likely add between 10 to 20 million Pound to the incident’s total costs.

Advanced is a major IT and software provider to healthcare organizations including the NHS. In August 2022, Advanced was compromised, attackers gained access to its health and care subsidiary resulting in a serious ransomware incident. The breach disrupted critical services including NHS 111 and prevented healthcare staff from accessing personal data on 79,404 individuals, including sensitive care information.

The ICO concluded that Advanced had incomplete MFA coverage, lacked comprehensive vulnerability scanning and had deficient patch management practices at the time of the incident – factors that collectively represented a failure to implement appropriate technical and organizational measures. Organizations processing sensitive data must treat security controls as non-negotiable. Inadequate patch management remains one of the most exploited gaps in modern attack chains.

Double Trouble: Backups Are Critical to Ransomware Mitigation

Backups are an organization’s last defense against ransomware and most sophisticated advanced persistent threat (APT) actors are known to target their victim’s backups. If a victim’s backups are compromised, submission to ransom demands is more likely. In 2025, this could mean multi-million Dollar losses. In March 2025, two new significant threats to backup services were revealed; CVE-2025-23120, a new critical severity flaw in Veeam was disclosed, and campaigns targeting CVE-2024-48248 in NAKIVO Backup & Replication were observed. Identifying affected systems and patching them is therefore an urgent matter.

In October 2024, our threat report alerted about another vulnerability in Veeam (CVE-2024-40711) being used in ransomware attacks. Overall, CVEs in Veeam Backup and Replication have a high conversion rate for active exploitation, PoC (Proof of Concept) exploits, and use in ransomware attacks. Here are the details for both emerging threats:

  • CVE-2024-48248 (CVSS 8.6): Versions of NAKIVO Backup & Replication before 11.0.0.88174 allow unauthorized Remote Code Execution (RCE) via a function called getImageByPath which allows files to be read remotely. This includes database files containing cleartext credentials for each system that NAKIVO connects to and backs up. A full technical description and proof-of-concept is available and this vulnerability is now tracked as actively exploited.
  • CVE-2025-23120 (CVSS 9.9): Attackers with domain user access can trigger deserialization of attacker-controlled data through the .NET Remoting Channel. Veeam attempts to restrict dangerous types via a blacklist, but researchers discovered exploitable classes (xmlFrameworkDs and BackupSummary) not on the list. These extend .NET’s DataSet class – a well-known RCE vector – allowing arbitrary code execution as SYSTEM on the backup server. The flaw is the subject of national CERT alerts globally including HK, CERT.be, and CERT-In. As per Veeam’s advisory, upgrading to version 12.3.1 is the recommended way to mitigate the vulnerability.

Greenbone is able to detect vulnerable NAKIVO and Veeam instances. Our Enterprise Feed has an active check [1] and version check [2] for CVE-2024-48248 in NAKIVO Backup & Replication, and a remote version check [3] for the Veeam flaw.

IngressNightmare: Unauthenticated Takeover in 43% of Kubernetes Clusters

Kubernetes is the most popular enterprise container orchestration tool globally. Its Ingress feature is a networking component that manages external access to services within a cluster, typically HTTP and HTTPS traffic. A vulnerability dubbed IngressNightmare has exposed an estimated 43% of Kubernetes clusters to unauthenticated remote access – approximately 6,500 clusters, including Fortune 500 companies.

The root-cause is excessive default privileges [CWE-250] and unrestricted network accessibility [CWE-284] in the Ingress-NGINX Controller tool, based on NGINX reverse proxy. IngressNightmare allows attackers to gain complete unauthorized control over workloads, APIs or sensitive resources in multi-tenant and production-grade clusters. A full technical analysis is available from the researchers at Wiz, who pointed out that K8 Admission Controllers are directly accessible without authentication by default, presenting an appealing attack surface to hackers.

The full attack trajectory to achieve arbitrary RCE against an affected K8 instance requires exploiting Ingress-NGINX. First, CVE-2025-1974 (CVSS 9.8) to upload a binary payload as the request body. It should be larger than 8kb in size while specifying a Content-Length header larger than the actual content size. This triggers NGINX to store the request body as a file, and the incorrect Content-Length header means the file will not be deleted as the server waits for more data [CWE-459].

The second stage of this attack requires exploiting CVE-2025-1097, CVE-2025-1098, or CVE-2025-24514 (CVSS 8.8). These CVEs all similarly fail to properly sanitize input [CWE-20] submitted to Admission Controllers. Ingress-NGINX converts Ingress objects to configuration files and validates them with the nginx -t command, allowing attackers to execute a limited set of NGINX configuration directives. Researchers found the ssl_engine module can be triggered to load the shared library binary payload uploaded in the first stage. Although exploitation is not trivial and no public PoC code exists yet, sophisticated threat actors will easily convert the technical analysis into effective exploits.

The Canadian Centre for Cyber Security has issued a CERT advisory (AV25-161) for IngressNightmare. Patched Ingress-NGINX versions 1.12.1 and 1.11.5 are available and users should upgrade as soon as possible. If upgrading the Ingress NGINX Controller is not immediately possible, temporary workarounds can help reduce risk. Strict network policies can restrict access to a cluster’s Admission Controllers allowing access to only the Kubernetes API Server. Alternatively, the Admission Controller component of Ingress-NGINX can be disabled entirely.

Greenbone is able to detect IngressNightmare vulnerabilities with an active check that verifies the presence of all CVEs mentioned above [1][2].

CVE-2025-29927: Next.js Framework Under Attack

A new vulnerability in Next.js, CVE-2025-29927 (CVSS 9.4) is considered high risk due the framework’s popularity and the simplicity of exploitation [1][2]. Adding to the risk, PoC exploit code is publicly available and Akamai researchers have observed active scans probing the Internet for vulnerable apps. Several national CERTs (Computer Emergency Response Teams) have issued alerts for the issue including CERT.NZ, Australian Signals Directorate (ASD), Germany’s BSI Cert-Bund (WID-SEC-2025-062), and the Canadian Centre for Cyber Security (AV25-162).

Next.js is a React middleware framework for building full-stack web applications. Middleware refers to components that sit between two or more systems and handle communication and orchestration. For web-applications, middleware converts incoming HTTP requests into responses and is often also responsible for authentication and authorization. Due to CVE-2025-29927, attackers can bypass Next.js middleware authentication and authorization simply by setting a malicious HTTP header.

If using HTTP headers seems like a bad idea for managing a web application’s internal process flow, CVE-2025-29927 is the evidence. Considering user-provided headers were not correctly distinguished from internal ones, this vulnerability should attain the status of egregious negligence. Attackers can bypass authentication by simply adding the `x‑middleware‑subrequest` header to a request and overloading it with at least as many values as the MAX_RECURSION_DEPTH which is 5. For example:

`x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware`

The flaw is fixed in Next.js versions 15.2.3, 14.2.25, 13.5.9 and 12.3.5, and users should follow the vendor’s upgrade guide. If upgrading is infeasible, it is recommended to filter the `x-middleware-subrequest` header from HTTP requests. Greenbone is able to detect vulnerable instances of Next.js with an active check and a version check.

Summary

The March 2025 threat landscape was shaped by vulnerable and actively exploited backup systems, unforgivably weak authentication logic, high-profile regulatory fines and numerous other critical software vulnerabilities. From the U.S. Treasury breach to the Advanced ransomware fallout, the theme is clear: trust doesn’t grow on trees. Cybersecurity resilience must be earned; forged through layered security controls and backed up by accountability.

Greenbone continues to play a vital role by providing timely detection tests for new emerging threats and standardized compliance audits that support a wide array of enterprise architectures. Organizations that want to stay ahead of cyber crime need to proactively scan their infrastructure and close security gaps as they appear.

Contact Test Now Buy Here Back to Overview

/by
Greenbone AG

Greenbone Enterprise Products Lead all Network Vulnerability Scanners

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.

Contact Test Now Buy Here Back to Overview

/by