Severity Rationale for Stored XSS and SSRF Findings

In Checkmarx SAST, the severity ratings for Stored XSS and Server-Side Request Forgery (SSRF) have been updated to better reflect realistic risk in the absence of full context. Specifically, SSRF has been raised from Medium to High, and Stored XSS from High to Critical.

These changes are grounded in how Checkmarx SAST approaches static analysis: we assess and assign severity to weaknesses, not confirmed vulnerabilities.

A weakness is a code pattern that, under the right conditions, could lead to a vulnerability. Since SAST operates without knowledge of the full runtime environment, user roles, or network architecture, it cannot definitively determine whether the conditions for exploitation are present. Unlike dynamic testing or exploit confirmation, static analysis can only infer potential risk. As such, severity is assigned based on worst-case scenarios that are not only possible, but likely and frequently encountered in real-world applications.

For Stored XSS, the move from High to Critical reflects the realistic assumption that a script injected by a low-privilege user could execute in a public or shared part of the application, potentially compromising a privileged account. If the compromised user has administrative capabilities, such as running commands, accessing sensitive data, or performing critical operations, the resulting impact could span the entire application’s confidentiality, integrity, and availability. Because these scenarios are common, and because SAST cannot rule them out, we assign a severity of Critical by default. This aligns with how similar issues are treated in security advisories and real-world exploit cases.

SSRF was previously rated as Medium, but has been increased to High. This change reflects the fact that even basic SSRF weaknesses - where user-controlled input is used in outbound server requests - can lead to serious outcomes. Attackers may exploit SSRF to bypass authentication flows, extract internal tokens, or pivot into internal networks. While the actual impact depends heavily on the specific services and architecture in place, these are not edge cases - they are well-documented attack patterns. Since SAST cannot determine whether safeguards like URL whitelisting, internal segmentation, or request sanitization are present, it’s safer and more accurate to treat SSRF as a High severity weakness unless proven otherwise.

By making these adjustments, Checkmarx aims to better align our severity ratings with modern threat models, prevalent attack techniques, and the limitations of static analysis. These ratings are not meant to suggest that every instance of Stored XSS or SSRF is actively exploitable, but rather that the underlying weakness, if left unmitigated, poses a real and significant risk in many deployment environments.

If you have sufficient application context, such as tightly scoped user roles, limited server permissions, or architectural constraints, you may choose to adjust the severity during triage. However, in the absence of such evidence, these elevated ratings represent a more accurate default posture for risk assessment.