Threat researchers

Blogs

NIST & CISA Proposed Metric for Vulnerability Exploitation Probability

The National Institute of Standards and Technology (NIST) is proposing a new metric to determine the likelihood of any software or hardware vulnerability being exploited.

The new metric is “Likely Exploited Vulnerabilities” (LEV), that aims to close a key gap in vulnerability management.

This new data point can benefit the SecOps teams who are working to release an effective patch management strategy and address the development flaws.

NIST now wants members of cyber security community to come forward and validate the method as predicting which ones is important for the efficiency and cost effectiveness of enterprise vulnerability remediation.

However NIST proposed that predicting ones which is important for the efficiency and cost effectiveness of enterprise vulnerability remediation efforts is important.

Currently, such remediation efforts rely on the Exploit Prediction Scoring System (EPSS), which has known inaccurate values, and Known Exploited Vulnerability (KEV) lists, which may not be comprehensive.

The proposed likelihood metric may augment EPSS remediation (correcting some inaccuracies) and KEV lists (enabling measurements of comprehensiveness). However, collaboration with industry is necessary to provide necessary performance measurements.

Importance of Metric for Vulnerability Exploitation Probability

Remediating vulnerabilities is time-consuming and costly. According to the paper, most companies only manage to patch about 16% of the vulnerabilities affecting their systems each month.

Meanwhile, research shows that only about 5% of vulnerabilities are exploited in the wild.

It is found organizations would spend their limited resources patching that small but dangerous subset, but identifying them has proven difficult.

That’s where LEV comes in to assist organizations prioritize vulnerabilities that are likely to have already been used in attacks, the metric could make patching efforts more targeted and effective.

In a recently published paper, Peter Mell (formerly of NIST) and Jonathan Spring of CISA presented a vulnerability exploitation metric that builds upon the existing Exploit Prediction Scoring System (EPSS) and CISA’s Known Exploited Vulnerabilities (KEV) catalog.

The researchers noted that studies show only about 5% of known vulnerabilities are exploited in the wild, while organizations typically remediate only 16% of vulnerabilities each month.

The researchers outline four key ways LEV could be used:

1. Estimate how many vulnerabilities have been exploited.
2. Check how complete KEV lists are.
3. Identify high-risk vulnerabilities missing from those lists.
4. Fix blind spots in EPSS, which sometimes underestimates risk for already-exploited bugs.

Introducing the LEV Metric

Mell and Spring’s new metric—called Likely Exploited Vulnerabilities (LEV) probabilities—aims to address the limitations of both EPSS and the KEV catalog. While EPSS provides 30-day exploitation probabilities, it has known inaccuracies, particularly underestimating risk for already-exploited vulnerabilities. KEV, on the other hand, is limited by its reliance on known exploit data and may not be comprehensive.

LEV probabilities are designed to:

  • Estimate how many and which vulnerabilities are likely to have been exploited
  • Assess the completeness of the KEV catalog
  • Enhance KEV-based prioritization by identifying likely-exploited vulnerabilities not yet listed
  • Improve EPSS-based prioritization by correcting underestimations

Key Findings

The researchers compared LEV and EPSS scores for specific vulnerabilities, showing significant differences.

For example:

  • CVE-2023-1730 (SupportCandy WordPress plugin SQL injection): before 3.1.5, the LEV probability was 0.70, while the peak EPSS score was 0.16.
  • CVE-2023-29373 (Microsoft ODBC Driver RCE – Remote Code Execution vulnerability): the LEV probability was 0.54350, while the peak EPSS probability was 0.08.

The LEV analysis identified hundreds of vulnerabilities with probabilities near 1.0. However, many of these are not listed in current KEV catalogs. NIST is actively seeking collaboration with partners as real-world validation is must for LEV to be a promising idea rather than a trusted tool.

NIST is currently seeking industry partners with relevant datasets to empirically evaluate the effectiveness of LEV probabilities through real-world performance measurements.

Sources: https://www.helpnetsecurity.com/2025/05/26/nist-likely-exploited-vulnerabilities/#:~:text=LEV%20aims%20to%20bridge%20that,%2C%20not%20replace%2C%20existing%20methods.

Security Advisory

Phishing Crusade Targeted approx 12,000 GitHub Repositories; Victims directed to “gitsecurityapp”

A large-scale phishing campaign has targeted nearly 12,000 GitHub repositories with phony security alerts, reported BleepingComputers.

The alerts, opened as issues on the repositories, inform users of unauthorized login attempts and provide links to change their passwords, review active sessions, or set up MFA.

If a user clicks any of these links, they’ll be taken to a GitHub authorization page for an OAuth app that will grant the attacker control of the account.

The campaign is ongoing, though GitHub appears to be responding to the attacks.

Users were directed to all links within the message to a GitHub authorization page for a malicious OAuth application called “gitsecurityapp.” If authorized, the app grants attackers full control over the user’s account and repositories, including the ability to delete repositories, modify workflows, and read or write organization data.

This consistent messaging across all affected repositories aims to create a sense of urgency and panic, prompting developers to take immediate action.

The fraudulent alert directs users to update their passwords, review active sessions, and enable two-factor authentication. However, these links lead to a GitHub authorization page for a malicious OAuth app named “gitsecurityapp.”

Upon authorization, an access token is generated and sent to various web pages hosted on onrender.com, granting the attacker full control.

(Image courtesy: Bleeping Computers)

The attack, which was first detected on March 16, remains active, though GitHub appears to be removing affected repositories.

Pointers Developers to take key inputs from this incident.

Last week, a supply chain attack on the tj-actions/changed-files GitHub Action caused malicious code to write CI/CD secrets to the workflow logs for 23,000 repositories.

If those logs had been public, then the attacker would have been able to steal the secrets.

The tj-actions developers cannot pinpoint exactly how the attackers compromised a GitHub personal access token (PAT) used by a bot to perform malicious code changes as per threat researchers.

Key pointers for User saftey:

  • For users who have mistakenly authorized the malicious OAuth app revoking access to suspicious OAuth apps through GitHub’s settings.
  • Affected users should review their repository workflows, check for unauthorized private gists, and rotate their credentials to prevent further damage.
  • This attack highlights the increasing threat of phishing campaigns targeting GitHub users.
  • As GitHub continues to investigate and respond, developers must remain vigilant and verify any security alerts before taking action.
  • Rotate your credentials and authorization tokens.

 Wiz suggests that potentially impacted projects run this GitHub query to check for references to reviewdog/action-setup@v1 in repositories.

If double-encoded base64 payloads are found in workflow logs, this should be taken as a confirmation their secrets were leaked.

Developers should immediately remove all references to affected actions across branches, delete workflow logs, and rotate any potentially exposed secrets.

(Sourece: Bleeping computers)

Scroll to top