Vulnerability Severity Levels

Invicti scans for a wide variety of vulnerabilities in websites, web applications, and web services. Invicti's automation makes it easy to scan websites and prioritize the findings, helping you decide which ones to tackle first, based on defining acceptable risks from a corporate point of view.

Each vulnerability has a different impact:

• Some detected vulnerabilities need to be addressed urgently because they cause the application to be compromised or damaged by attackers (Critical, High), while others are less of a priority (Low). For example, an SQL Injection vulnerability should definitely be prioritized over an Internal IP address disclosure.
• Some highlighted findings are simply notes that give information that is relevant to the target application's infrastructure. Others, such as Best Practice or Information Alerts, help website owners implement additional security measures.

What Are Vulnerability Severities?

To help you better decide which vulnerabilities should be fixed first, Invicti categorizes them using risk scores in its scans and reports. There are four vulnerability levels:

• Critical ()
• High ()
• Medium ()
• Low ()

There are two additional types of alerts: Best Practice () and Information Alerts (). 

For further information, refer to our Web Application Vulnerabilities Index.

Critical Severity Web Vulnerabilities

This section explains how we define and identify web vulnerabilities of critical severity ().

The issues marked as critical severity can allow attackers to execute code on the web application or application server, or access sensitive data.

What are the potential impacts of critical severity web vulnerabilities?

1. Examples include SQL Injection, Remote Code Execution, and Command Injections. In exploiting this type of vulnerability, attackers could carry out a range of malicious acts that could, for example, affect a web application's availability, or put its confidentiality and security at risk.

2. In addition, it is the existence and prevalence of automated exploitation tools that make fixing these types of issues urgent.

Example of a critical severity vulnerability

This is what a report of a critical severity vulnerability looks like in Invicti Enterprise.

Suggested action for critical severity vulnerabilities

A critical severity vulnerability means that your website is at risk of being hacked at any time. We recommend that you make it your highest priority to fix these vulnerabilities immediately.

High Severity Web Vulnerabilities

This section explains how we define and identify web vulnerabilities of high severity ().

The issues marked as high severity can allow malicious attackers to access application resources and data. This can allow an attacker to steal session information or sensitive data from the application or server.

The difference between critical and high severity is that with a high severity vulnerability, a malicious attacker cannot execute code or a command on the application or server.

What are the potential impacts of high severity vulnerabilities?

1. Examples include XSS, XML External Entity Injection, and LFI.
   In the case of a detected XSS vulnerability, an attacker could:

• Execute script code in the user's browser
• Steal the user's cookies

In the case of a detected XXE vulnerability, an attacker could:

• Read sensitive data in the server
• Make requests to internal or external resources

2. Attackers conducting this type of attack have some technical skills, but many tools make the exploitation process automated.

Example of a high severity vulnerability

This is what a report of a high severity vulnerability looks like in Invicti Enterprise.

Suggested action for high severity vulnerabilities

A high severity vulnerability means that your website can be hacked and can lead hackers to find other vulnerabilities which have a bigger impact. We recommend that you fix these types of vulnerabilities immediately.

Medium Severity Web Vulnerabilities

This section explains how we define and identify vulnerabilities of medium severity ().

The issues marked as medium severity usually arise because of errors and deficiencies in the application configuration. By exploiting these security issues, malicious attackers can access sensitive information on the application or server.

In comparison to critical and high severity issues, the impact is relatively limited.

What are the potential impacts of medium severity vulnerabilities?

1. Attackers conducting this type of attack require more skill than those exploiting critical and high severities.
2. Exploitation of these types of vulnerabilities can depend on the existence of some special conditions. For example, in the case of SSL/TLS certificate issues, or misconfiguration of TLS, an attacker has to be in an appropriate location to be able to eavesdrop on the connection of the victim.

Example of a medium severity vulnerability

This is what a report of a medium severity vulnerability looks like in Invicti Enterprise.

Suggested action for medium severity vulnerabilities

Even though special conditions are required to exploit medium severity issues, and they don't directly affect the application or system (in contrast to critical and high severities), in order to keep your web application secure and comply with the regulations, they should still be fixed.

Low Severity Web Vulnerabilities

This section explains how we define and identify web vulnerabilities of low severity ().

The issues marked as low severity include information leakage, configuration errors, and a lack of some security measures. They can be combined with other issues of a higher severity level and can be used in conjunction with social engineering (manipulating people into following certain actions or revealing crucial information), to cause a more severe impact on the target.

In comparison to critical, high, and medium severity issues, these findings have limited effect.

What are the potential impacts of low severity vulnerabilities?

1. When a website reveals the version number of an application, an attacker can carry out vulnerability mapping by looking at the vulnerability database to see if an issue exists in that version of the application and then exploiting it.
2. Invicti reports Username Disclosure vulnerabilities when related to Windows or Linux operating systems or RDBMS. Though they are flagged as low-level vulnerabilities by themselves, an attacker could use this information to find a way to access the target application's operating system or database system.
3. In the case of application configuration errors and deficiencies such as an X-Frame-Options header (XFO) – which controls whether a website is loaded by itself, another site or neither – Invicti reports a missing XFO if the scanned web application does not set, or mistakenly sets, the XFO header. An attacker could exploit these configuration errors by convincing an authorized user to click on a malicious link or button (a potentially state-changing operation), which could result in the deletion of records or uncover hidden resources. 

Example of a low severity vulnerability

This is what a report of a low severity vulnerability looks like in Invicti Enterprise.

Suggested action for low severity vulnerabilities

A decision on whether to fix these issues should be determined by assessing the context in the application, and by considering the business impacts.

Best Practice

This section explains how we define and identify issues that are marked as best practice ().

Making web applications secure involves more than taking rapid action on detected vulnerabilities. Browser vendors offer various features that make being proactive easier than ever. These preemptive standards and recommendations help software developers make web applications that are secure by design.

What are the potential impacts of best practice issues?

1. The issues marked as best practice are recommendations, not vulnerabilities.
   Examples include Content Security Policy, Referrer-Policy, Expect-CT, Subresource Integrity – security implementations that are provided by browser vendors. Think of these recommendations as an extra security layer, defense in depth, to help continually contribute to the security of your web applications – proactively.
2. Invicti Enterprise makes suggestions around these standards and reports errors and issues in the implementation of them.

Example of a best practice issue

This is what a report of a best practice issue looks like in Invicti Enterprise.

Suggested action for best practice issues

Invicti recommends that these best practice suggestions are implemented in order to make your web application secure.

Information Alerts

This section explains how we define and identify issues that are marked as information alerts ().

The findings reported are mostly for informing you about the target's ingredients and infrastructure. They help you to understand the application's technology stack and dependencies well.

What are the potential impacts of information alerts?

1. The issues highlighted in these alerts can help attackers understand the target more and therefore tailor their attack better, eliminate other possibilities and conduct vulnerability mapping.
2. For example, revealing that a website uses a certain IIS version does not seem that important at first sight. However, it means that the OS of the target web application is a Windows OS, for example. So, an attacker can eliminate attack possibilities regarding other operating systems. In addition, vendors who use IIS tend to prefer application infrastructures offered by Microsoft. An attacker could reasonably assume that the target application was developed using either ASP or .NET technologies. This can further help them eliminate other attack possibilities regarding other application infrastructure and save time.
3. In the case of vulnerability mapping, if the target uses older versions of IIS that have known security issues, this can allow a target machine to be compromised by an attacker. For instance, CVE-2017-7269 was an issue in IIS 6.0 and exploited since 2016. It allows remote attackers to execute arbitrary code in the target. (Please note that in the case of an out-of-date component, and an associated vulnerability, this would be reported at a higher level than information alert.

Example of an information alert

This is what a report of an information alert issue looks like in Invicti Enterprise.

Suggested action for information alerts

Most of the time, there is no need to take any action for information level findings. This is why Invicti Enterprise marks them as accepted risk.

However, it is recommended that you manually review information alert findings and modify the application to avoid revealing details that give hints or information regarding the application itself.