Docs
← Home Sign In Get Started

The five severity levels

Every finding is assigned one of five severity levels. Severity reflects the potential impact if the vulnerability were exploited under typical conditions.

LevelCVSS rangeMeaningAction
CRITICAL 9.0 – 10.0 Direct exploitation possible with high impact on confidentiality, integrity, or availability Fix immediately
HIGH 7.0 – 8.9 Significant risk. Exploitation likely in common attack scenarios Fix this sprint
MEDIUM 4.0 – 6.9 Moderate risk. May require specific conditions or user interaction to exploit Fix next release
LOW 0.1 – 3.9 Minor risk or best-practice violation with limited practical impact Add to backlog
INFO N/A Informational finding. No exploitable risk, but worth knowing Review as needed

Critical examples

  • SQL Injection with database error confirmation (CVSS 9.8)
  • Server-Side Template Injection (SSTI) — potential RCE (CVSS 9.8)
  • SSRF via user-controlled URL parameter (CVSS 9.3)
  • Insecure deserialization indicators (CVSS 9.8)

High examples

  • Stored XSS — user input persisted and reflected without encoding (CVSS 8.8)
  • HTTP Request Smuggling indicators (CVSS 8.1)
  • Broken Access Control — sensitive admin paths accessible without auth (CVSS 8.1)
  • Expired or self-signed SSL certificate (CVSS 7.4)

Medium examples

  • Reflected XSS — payload reflected but requires user interaction (CVSS 6.1)
  • Open Redirect — attacker can redirect users to malicious sites (CVSS 6.1)
  • Missing HSTS header (CVSS 5.9)
  • CORS misconfiguration allowing cross-origin credential sharing (CVSS 6.5)
  • Weak TLS version (TLS 1.0/1.1) still supported (CVSS 5.3)

Low examples

  • Server version disclosed in Server header (CVSS 3.7)
  • Missing X-Content-Type-Options header (CVSS 3.1)
  • Directory listing enabled on non-sensitive path (CVSS 3.7)
  • Cookie missing SameSite attribute (CVSS 2.6)

Info examples

  • Technology stack detected (framework version, CMS type)
  • robots.txt entries noted (informational, no direct risk)
  • HTTP/2 not supported (performance note)
  • Missing ETag caching header

Interpreting severity in context

Shieldome assigns severity based on the generic CVSS score for each check. Your actual risk may be higher or lower depending on your application's context. Use this guide:

SituationEffect on real risk
Finding is on a page that requires authenticationRisk is usually lower — attacker needs an account first
Finding is on a public-facing login or payment pageRisk is usually higher — high-value target
Target stores PII, health, or financial dataUpgrade your remediation priority by one level
Target is an internal tool with no internet exposureRisk is lower — network-level controls provide defence in depth
Finding matches a known active exploit in the wildTreat as one level higher and patch immediately
ℹ️
Severity is assigned by Shieldome and cannot be overridden in the tool. If you disagree with a severity rating in context, note it in the scan's Notes field and document your reasoning. For false positives, see the False Positives guide.