CVE is an acronym that stands for Common Vulnerabilities and Exposures.

CVEs offer information about security issues impacting the technologies (e.g., hardware, operating systems, applications, and programs) people depend on day to day. These vulnerabilities and exposures are identified by individuals or teams of security researchers, labeled by accredited CVE numbering authorities, and subsequently compiled in public databases for easy public access.

The goal of CVE research is to rapidly increase public awareness of zero-day cybersecurity threats and improve the public’s ability to respond to these threats in a timely manner.

Discovering and Labeling CVEs

The process of labeling CVEs for public discovery is carried out by one of several CVE Numbering Authorities (CNAs). CNAs include dozens of well-known technology corporations, such as Microsoft, Oracle, Cisco, and others.

The CVE program itself is organized by the MITRE corporation, which is a non-profit federally funded group affiliated with the United States Department of Homeland Security. In addition to overseeing the CVE program, MITRE can also issue CVEs directly. CVEs appear in several public databases, including the United States National Vulnerability Database (NVD).

When a CNA identifies a new vulnerability or exposure, they assign the CVE a prefix followed by an identifying number (e.g., CVE-2023-5474). This identification makes it easy to quickly search for information about any given CVE in a CVE database. Since thousands upon thousands of CVEs are published to CVE databases every year, CNAs are issued CVE identifiers in advance of each new year, and these identifiers are assigned to new vulnerabilities and exposures as they’re discovered.

While CNA’s play a key role in organizing and identifying CVEs for public review, the initial discovery of new vulnerabilities and exposures isn’t limited to those affiliated with CNA organizations. A new CVE can, for example, be discovered by an end user noticing a flaw in an application they use at work. The user discovering the flaw can report the vulnerability to a CNA through any one of a variety of different channels, and the CNA can then verify the flaw and assign a CVE identifier to it.

Often, CNAs and other non-CNA technology corporations incentivize the discovery of new CVEs in their products through bug bounty programs. Developers, administrators, and other technical folks can earn a cash reward for identifying relevant vulnerabilities and exposures in popular software products.

When a new CVE is committed to a CVE database, a short description of the vulnerability or exposure is included that succinctly describes the issue. Links and additional references are included alongside the CVE description to facilitate further research for the public, and statements from the affected technology’s vendor about updates, patches, etc. are typically soon to follow. In many cases, information about a new CVE won’t be published at all until the vulnerability or exposure in question has been addressed and resolved the by relevant technology vendor.

What Constitutes a CVE?

A plethora of issues are identified in the technologies we use day to day, but not all these issues can be considered CVEs. New vulnerabilities and exposures can be generally defined by the following criteria:

Impact

A CVE should have an identifiable impact on the confidentiality, integrity, or availability of the affected system. This impact could include anything from unauthorized access to system crashes or unauthorized control of a system.

Reproducibility

A CVE must be reproducible. When a potential vulnerability or exposure is brought to the attention of a CNA, a member of the CNA must be able to recreate the issue in their own environment. Once the issue is reproduced, the affected technology vendor can be notified, and the process of patching the issue can begin.

Scope

A public CVE should be a problem that impacts a significant number of users. It’s difficult to define a minimum threshold for the scope of a CVEs impact, but it’s generally only worth disclosing publicly if there’s a real incentive for threat actors to exploit the vulnerability in question.

Documentation

A CVE report should come along with a significant amount of relevant documentation (i.e., evidence that the CVE exists with specific descriptions about the method of exploitation). Documentation should include key information about the affected technology and steps for reproducing the flaw in question. For example, reports on software vulnerabilities and exposures should contain information about the specific software version(s).

Independence and Assignability

New CVEs reports should describe unique flaws which are clearly distinguished from existing CVEs in a CVE database. In other words, duplicate CVEs should be avoided as much as possible to avoid clutter in a CVE database.

Scoring CVEs

New CVEs are assigned scores through a few different scoring systems to ensure the relative severity of any given vulnerability or exposure is adequately communicated to the public. CVE scores effectively help organizations prioritize and address certain vulnerabilities and exposures ahead of others.

The most common CVE scoring system is the Common Vulnerability Scoring System (CVSS).

The CVSS is a standardized, widely accepted method for evaluating the impact of vulnerabilities; it’s used heavily by vendors, security researchers, and organizations to consistently communicate the severity of vulnerabilities.

A CVSS score can range from 0.0 to 10.0, with higher numbers indicating more severe vulnerabilities. Each range of scores is categorized as Low Severity, Medium Severity, High Severity, or Critical Severity.

Low Severity CVSS Rating

Scores between 0.1 – 3.9 receive a Low Severity rating.

Medium Severity CVSS Rating

Scores between 4.0 – 6.9 receive a Medium Severity rating.

High Severity CVSS Rating

Scores between 7.0 – 8.9 receive a High Severity rating.

Critical Severity CVSS Rating

Scores between 9.0 – 10.0 receive a Critical Severity rating.

The CVSS provides a base score representing the intrinsic qualities of any given vulnerability. This is typically calculated based on the access complexity of the vulnerability (i.e., how easy it is to exploit), the vulnerability’s authentication requirements, and the impact the vulnerability can have on exploitation outcomes such as data confidentiality, data integrity, system availability, etc.

The CVSS also provides a temporal score reflecting a vulnerability’s exploitability relative to the availability of vulnerability mitigations. For example, vulnerabilities that have readily available patches and/or workarounds will receive a lower temporal score than vulnerabilities without immediate fixes.

Protecting Your System Against New CVEs with Cloudmersive APIs

Every day, a wide range of zero-day CVEs are discovered in the rendering and processing programs that our file processing applications use to load and display file content. Threat actors can, for example, intentionally manipulate the contents of common image files (e.g. .JPG, .PNG, .WEBP, etc.) to exploit hidden flaws in our image rendering programs, and these malicious files can cause Heap-Based Buffer Overflows or Stack-Based Buffer Overflows resulting in data leaks, data corruption, and even Distributed Denial of Service (DDoS) attacks. Attacks exposing these zero-day exploits don't necessarily involve viruses or malware of any kind, making it difficult to mitigate them with traditional antivirus software.

The Cloudmersive Advanced Virus Scan API specializes in protecting networks, applications, and cloud storage databases against myriad vulnerabilities and exposures related to invalid and maliciously crafted file uploads. In addition to referencing files against a continuously updated list of more than 17 million virus and malware signatures, the Advanced Virus Scan API performs in-depth content verification for each scanned file, ensuring files rigorously conform to expected file formatting requirements.

With Cloudmersive content verification, abnormally formatted files can be identified before reaching potentially vulnerable programs, ensuring relevant zero-day CVE exploits won’t impact our system architecture.

For more information on Cloudmersive Virus Scan APIs, please do not hesitate to reach out to a member of our team.