How to Explore Vulnerabilities

Google Threat Intelligence helps you prioritize patching and mitigation efforts by providing empirical risk scoring, highly contextualized correlations to other indicators of compromise (IOCs, or simply "indicators"), and continuously updated reporting for Vulnerabilities.

Explore Vulnerabilities

1. To explore Vulnerabilities, click Vulnerability Intelligence.

2. The dashboard displays the Vulnerabilities List: A filterable and sortable list of over 100K Vulnerabilities being tracked by Google Threat Intelligence.

   

3. See the Vulnerability Summary of a vulnerability on the results list.

Below is a breakdown of each component in the summary card.

• Selection Checkbox: Allows you to select one or more vulnerabilities for bulk actions, such as Follow or Run TTP Analysis.
• Vulnerability Identifier (CVE): The primary Common Vulnerabilities and Exposures (CVE) identifier.
• Update Status: Shows when the information for this vulnerability was last updated in the system.
• Vulnerability Summary: A brief, human-readable description of the vulnerability, including its type and the potential impact if exploited.
• Intelligence Source: Identifies the organization that provided or curated this threat intelligence data. Here, it is "Google Threat Intelligence".
• First Published Date: The date when the CVE was initially published, providing historical context.
• Risk Rating: A classification of the vulnerability's overall severity, typically categorized as Low, Medium, High, or Critical.
• Exploit Availability: Indicates whether exploit code or a proof-of-concept (PoC) is publicly available.
• Exploitation State: Specifies whether there are known instances of this vulnerability being exploited. "No Known" means that while an exploit may be available, there is no current intelligence confirming its use in attacks.
• Exploited as Zero Day: A "Yes" or "No" flag indicating if the vulnerability was exploited by attackers before a patch was made available by the vendor.
• Exploited in the Wild: A "Yes" or "No" flag indicating if the vulnerability is being actively used in real-world attacks.
• Indicators of Compromise (IoCs): The number of IoCs (such as file hashes, IP addresses, or domains) associated with this vulnerability in the platform's database.
• Activity Timeline: A small sparkline graph that visualizes the activity level or mentions of this vulnerability over time, helping to identify recent spikes in interest or exploitation.

4. Click on the name of a vulnerability to explore the complete Vulnerability profile across several tabs as detailed in this article

ℹ️

Any aliases for the Vulnerability are listed beneath its CVE ID, including its MVE ID. MVEs are Google Threat Intelligence's unique IDs for Vulnerabilities, similar to CVEs (Common Vulnerabilities and Exposures).

Filtering Vulnerabilities

• Go to Vulnerability Intelligence.

• In the Filters pane, select the desired filters based on the following options:

  • Creation Date: Date when information on the Vulnerability was created.

  • Last Modification Date: Date when Google Threat Intelligence last published updates regarding the Vulnerability.

  • Risk Rating: Google Threat Intelligence Group’s Risk Rating is our expert assessment of what impact an attacker could have on a targeted organization if they were to exploit a vulnerability. To determine Risk Rating, analysts typically start by identifying and understanding the underlying consequence (or the underlying vulnerability type, which sometimes carry an inherent consequence), then adjust the Risk Rating accordingly based on additional, identified mitigating factors (a list of which can be found later in this document). The below guidelines represent the most common examples of how vulnerabilities are inherently scored by analysts, but exceptions in our dataset exist due to the variety of, and in some cases unique combination of, factors we consider when scoring vulnerabilities.

    • Unrated: Some Vulnerabilities do not have a Google Threat Intelligence risk rating but do have the other Vulnerability intelligence context included. This is usually because there is insufficient information to determine the risk rating, or it's still being analyzed.
    • Low: Exploitation of these vulnerabilities would have little to no security impact on targeted systems. This means that while technically a vulnerability, there is little to no direct, notable security impact an attacker can have on the targeted system or network.
      Examples of low risk vulnerabilities include, but are not limited to:
      • Exploitation consequence resulting in leak or modification of low-value information
      • Exploitation consequence resulting in temporary or local denial-of-service (DoS)
      • Exploitation consequence of code execution resulting from cross-site scripting (XSS)
      • Vulnerabilities with vulnerability type of Observable Timing Discrepancy
      • Vulnerabilities that require exploitation vector of bluetooth access or physical access without a specified consequence
      • Exploitation consequence resulting in spoofing of visual components
    • Medium: Exploitation of these vulnerabilities would either enable attackers to perform additional activities on the targeted device or network or could enable attackers to have a direct, notable impact on the security of the targeted device or network, but would require notable additional factors to be performed or mitigated.
      Examples of medium risk vulnerabilities include, but are not limited to:
      • Exploitation consequence of privilege escalation (excluding gaining root or other significant, system-level access roles)
      • Exploitation consequence resulting in persistent DoS of network devices
      • Exploitation consequence of code execution with notable mitigating factors (user interaction, high-level privileges, or access requirements)
      • Exploitation consequence of command execution with notable mitigating factors (user interaction, high-level privileges, or access requirements)
    • High: Exploitation of these vulnerabilities would enable attackers to have a notable, direct impact to the security of targeted devices and networks without needing to overcome any major mitigating factors.
      Examples of high risk impacts include, but are not limited to:
      • Exploitation consequence of DoS with safety concerns as defined by IEC 61508
      • Exploitation consequence of code execution with little to no mitigating factors
      • Exploitation consequence of command execution with little to no mitigating factors
      • Exploitation consequence of privilege escalation that enables root or other significant access roles
    • Critical: Exploitation of these vulnerabilities fundamentally undermine the security of affected devices and networks, enabling actors to perform significant attacks with minimal effort, impacting a wide number of systems, often with little to no mitigating factors to overcome. Reliability of exploitation is most likely very high and can almost certainly be performed effectively at scale.
      We intentionally use this rating sparingly, but is typically used in cases where exploitation has serious impact, exploitation is trivial with often no real mitigating factors, and attack surface is large and remotely accessible. Vulnerabilities rated critical should be considered as a recommendation for immediate prioritization for remediation. Examples of critical risk impacts include, but are not limited to:
    • CVE-2021-44228 (possibility of remote code execution, lack of requirement for user interaction or user permissions, widespread usage of vulnerable software, and embedded nature)
    • CVE-2024-1709 (potential for unauthorized access, trivial nature of exploitation, and potentially difficult remediation if successfully exploited).

    The above descriptions and examples are intended as a high-level understanding of Google Threat Intelligence Group’s Risk Rating and in no way is able or intended to capture the nuanced analysis or rating of each individual vulnerability. Rather, this should be used to understand the basic rating process. Additionally, while we consider some similar factors as CVSS, there is no correlation between our risk ratings and CVSS scores or ranges, and in most cases will differ.

• Predictive Risk Rating (PRR): Some Google Threat Intelligence Vulnerabilities have a Predicted Risk Rating, these are vulnerabilities that have not yet received an analyst provided risk rating.
  The pace at which vulnerabilities are being discovered and disclosed is ever increasing. Having an analyst look at every vulnerability in order to provide a rating is a process that can not scale to match that pace. Many vulnerabilities are low risk and would not be an effective use of an analyst’s time. With that, using a predicted rating system allows Google Threat Intelligence analysts to prioritize which vulnerabilities should be expert reviewed in order to maximize the value add.
  The PRR attempts to accurately predict the rating an analyst would give a specific vulnerability. To do this, the system looks at the following properties:

  • CWE
  • Exploitation Vector
  • Exploitation Consequence
  • Description
  • CVSSv3
  • CVSSv2
  • Risk Factors
    The PRR for a specific vulnerability is reevaluated every time a vulnerability object is updated with new information. This process continues until an analyst provides a risk rating for the vulnerability.

• Exploitation State: Google Threat Intelligence's Exploitation State indicates our knowledge of the current exploitation landscape, and whether a vulnerability is known or suspected to be exploited.

  • Wide: Exploitation of this vulnerability is occurring on a wide scale.
  • Confirmed: Google TI has observed exploitation of this vulnerability or has observed credible reporting that indicates that vulnerability is being actively exploited.
  • Reported: Reports of this vulnerability being exploited exist, although Google TI has yet to confirm the exploitation.
  • Suspected: Exploitation of this vulnerability has not been confirmed or reported, but we are aware of evidence that indicates explotiation may have occured or be occuring in the wild.
  • No Known: Google TI is unaware of reports of exploitation of this vulnerability. Google TI has not observed exploitation of this vulnerability.

• Exploitation Consequences
  • Code Execution: An attacker could exploit this vulnerability to execute arbitrary code, including installing and running applications.
  • Command Execution: An attacker could exploit this vulnerability to execute arbitrary commands on a vulnerable host.
  • Data Loss: An attacker could exploit this vulnerability to delete data.
  • Data Manipulation: An attacker could exploit this vulnerability to insert, delete, or modify data.
  • Denial-of-Service (DoS): An attacker could exploit this vulnerability to temporarily or permanently degrade or disable services.
  • Information Disclosure: An attacker could exploit this vulnerability to disclose sensitive or confidential information.
  • Unauthorized Access: An attacker could exploit this vulnerability to gain logical or physical access to a resource without having prior permissions.
  • Privilege Escalation: An attacker with existing privileges to an application or host could exploit the vulnerability to gain additional privileges.
  • Sandbox Escape: An attacker with the ability to execute code within a sandboxed process could exploit this vulnerability to bypass restrictions on the sandboxed process.
  • Security Bypass: An attacker could exploit this vulnerability to defeat or circumvent specific security mechanisms of a system.
  • Container Escape: An attacker could exploit this vulnerability to perform actions on the container's host.
  • Spoofing: An attacker could exploit this vulnerability to provide information or data that appears to be valid in order to trick a user or system into believing it is legitimate and possibly taking unintended action. This can include simple impersonation (email addresses, URLs, etc.) or manipulating a user's view (covered/unseen alerts or messages).
• Exploitation Vectors
  • Administrative Interface: Exploitation targets the administrative interface (e.g., login page, management console) of the application or appliance. This vector applies when the vulnerability is directly exploitable through actions performed via the administrative interface.
  • Bluetooth Access: Exploitation requires sending malicious traffic over the Bluetooth protocol.
  • Browser: Exploitation occurs when a user's browser processes malicious web content. This includes vulnerabilities like cross-site scripting (XSS), cross-site request forgery (CSRF), and other browser-based attacks.
  • Compromised Communication Channel: Exploitation requires an attacker to obtain access to the communication channel utilized by a vulnerable system. This can either be a read-only passive relay or active read-write modification of the communicated data.
  • Email: Exploitation requires a user or application to process (e.g., open, preview) a specially crafted email.
  • Exposed Web Application: Exploitation targets a publicly accessible web application (excluding administrative interfaces). This vector is for vulnerabilities in the general user-facing application itself, not specifically its administrative parts.
  • Local Network Access: Exploitation requires the attacker to be on the same logical network as the vulnerable application and send malicious traffic. This assumes network-level access, not direct system access. If user login or direct system access is required, use "Unspecified Local Vector" instead.
  • Malicious Application: Exploitation involves crafting a malicious application that, when executed by a user on a vulnerable system, triggers the vulnerability.
  • Malicious File: Exploitation requires a user to process (e.g., open, import, upload) a malicious file using a vulnerable application.
  • Malicious Server: Exploitation requires the vulnerable application to connect to a malicious server controlled by the attacker.
  • Open Port: Exploitation involves sending malicious traffic to a specific, publicly accessible open network port on the vulnerable system.
  • Physical Access: Exploitation requires the attacker to have physical access to the vulnerable device and perform actions directly on it.
  • Short Range Radio: Exploitation requires sending malicious traffic over a short-range radio protocol other than Bluetooth or Wi-Fi (e.g., NFC, Zigbee).
  • Unspecified Local Vector: Exploitation requires the attacker to have direct, local access to the vulnerable system and perform actions on it. This is used when the specific local vector isn't detailed but isn't physical access. Use if the user must be logged in to exploit, or the vulnerability requires local system privileges.
  • Unspecified Remote Vector: Exploitation occurs remotely over a network, but the exact vector is not specified in the advisory. Use this ONLY when no more specific remote vector can be determined.
  • VPN Access: Exploitation requires sending malicious traffic to a vulnerable application through a VPN connection.
  • WiFi Access: Exploitation requires the attacker to be on the same Wi-Fi network or within Wi-Fi range of the vulnerable target and send malicious traffic.

• Available Mitigations
  • Patch: Vendor fixes exist that mitigate the Vulnerability.
  • Workaround: A solution exists that can mitigate some exploitation attempts, but is not intended to be a full or permanent fix.
  • Intrusion Prevention Signatures: Intrusion prevention signatures exist capable of preventing exploitation attempts.
  • Firewall: Specific firewall rules can be used to prevent exploitation attempts.
  • Anti-Virus Signatures: Anti-virus signatures capable of detecting exploitation attempts exist.
  • Mitigated by vendor: The vendor has applied some form of mitigation on their end that fully mitigates potential exploitation of the vulnerability without any required customer actions.
• Vulnerability Filters
  • CISA Exploited: The Vulnerability appears in the Known Exploited Vulnerabilities Catalog of the Cybersecurity & Infrastructure Security Agency (CISA).
  • Zero-Day: The Vulnerability was known to be exploited prior to a patch being made available.
  • Observed In The Wild: Google Threat Intelligence has either observed malicious exploitation of a Vulnerability or has received information regarding confirmed exploitation from a reliable or confirmed source.
  • Affects Operational Technologies: The Vulnerability is known to affect operational technology (OT) and/or industrial control systems (ICS).
  • Affects Cloud: The Vulnerability is known to affects cloud services.
  • Requires User Interaction: The Vulnerability can only be exploited with the direct interaction from a potential target.
• CVSS v4 BT (Base and Threat): This metric group represents the intrinsic characteristics of a Vulnerability that are constant over time but not across user environments as well as the current state of exploit techniques or code availability for a vulnerability.
• CVSS 3.1 Base Score: Filter based on a range of CVSS 3.1 Base Score metrics.
• CVSS 3.1 Temporal Score: Filter based on a range of CVSS 3.1 Temporal Score metrics.
• CVSS 2.0 Base Score: Filter based on a range of CVSS 2.0 Base Score metrics.
• CVSS 2.0 Temporal Score: Filter based on a range of CVSS 2.0 Temporal Score metrics.