Common Vulnerability Scoring System(CVSS) is a numerical representation of the severity of a software vulnerability on a scale of 0-10. The final CVSS score is determined by the sub-categories from the 8 categories of options. This is a simplified version of the specification document by FirstOrg.
This metric reflects the context by which vulnerability exploitation is possible.
|Network||Remotely Exploitable via the Internet.|
|Adjacent||Attack via same shared physical or logical network. Example: Wi-Fi, Local IP subnet, Bluetooth|
|Local||Local access to system via keyboard, console or remotely like SSH or relies on user interaction such as Social Engineering.|
|Physical||Requires physical interaction with the vulnerable component.|
This metric describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability.
|Low||The exploit do not rely on special conditions or configurations on a target environment.|
|High||A successful attack depends on conditions beyond the attacker’s control. Example: knowledge on target environment and configuration is required, mitigation techniques should be bypassed|
This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.
|None||Attacker is an unauthenticated/unauthorized user.|
|Low||Attacker is an authenticated/authorized with low level privileges.|
|High||Attacker is an authenticated/authorized with highest level of privileges. Example: administrator|
This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner. Here, user is a target or an authorized personnel associated with a target.
|None||The vulnerable system can be exploited without interaction from any user.|
|Required|| Requires a user to take some action before the vulnerability can be exploited. Example: opening a link or a file|
This metric captures whether a vulnerability in one vulnerable component impacts resources in components beyond its security scope.
|Changed||An exploited vulnerability can only affect resources managed by the same security authority. Example: HTML Injection (the code runs in the context of the web application)|
|Unchanged||An exploited vulnerability can affect resources beyond the security scope managed by the security authority of the vulnerable component. Example: Remote Command Execution on a web application (the command is executed on the web server)|
This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability.
|High||Total loss of confidentiality. Example: plain-text password|
|Low||Some loss of confidentiality. Example: hashed password|
|None||No loss of confidentiality.|
This metric measures the impact to integrity (trustworthiness and veracity of information) of a successfully exploited vulnerability.
|High||Total loss of integrity. Example: all files can be modified|
|Low||Some loss of integrity. Example: limited modification of files|
|None||No loss of integrity.|
This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability.
|High||Total loss of availability. Example: permanent service interruption (repeated exploitation do not count as High)|
|Low||Some loss of availability. Example: temporary service interruption|
|None||No loss of availability.|
Lastly, CVSS score is always debatable and different in different people’s mind.