Understanding Security Vulnerability Grading: Levels, Upgrade Rules, and Common Types

Scope

This standard classifies security vulnerabilities into levels so that appropriate actions can be taken based on severity.

Security Vulnerability Grading Standard

S0 (Critical) : Vulnerabilities already announced or exploited that affect group systems/businesses, potentially causing system intrusion risk, massive sensitive data compromise, service availability loss, and asset damage. Handling time: 24 hours

S1 (High) : Announced or exploited vulnerabilities that may lead to customer data tampering or leakage and partial service availability impact. Handling time: 3 business days

S2 (Medium) : Internally discovered S0‑level issues that are not severely harmful, or unannounced exploitable vulnerabilities, possibly causing unauthorized personal data leakage, integrity damage to applications/services/computers/data, and partial user availability impact. Handling time: 5 business days

S3 (Low) : Unannounced exploitable vulnerabilities that lower service quality or cause system errors, or confirmed external reports that pose no known or potential harm. Handling time: 14 business days

S4 (Warning) : Currently non‑exploitable issues that contain insecure factors needing correction. Handling time: 60 business days

Vulnerability Level Upgrade Mechanism

A mechanism is introduced to raise the vulnerability level when any of the following occurs:

External report increases the level by one.

A previously undisclosed vulnerability becomes publicly disclosed during handling.

An unexploitable vulnerability becomes exploitable.

The handling duration exceeds the allowed time.

The vulnerability is widely exploited or results in massive information leakage.

If handling exceeds the allowed time, the level is incrementally raised until it reaches S0.

Common Vulnerability Security Levels

S0 (Critical) : Direct system‑level privilege escalation (e.g., remote command execution, arbitrary code execution, webshell upload, SQL injection leading to system rights, buffer overflow), denial‑of‑service attacks, severe sensitive data leaks (core DB), and serious logical or workflow design flaws.

S1 (High) : Sensitive information leakage (non‑core DB, source code, user‑info APIs), privilege escalation (bypassing authentication, weak admin passwords).

S2 (Medium) : Vulnerabilities requiring user interaction (reflected XSS, CSRF, URL redirects), local denial‑of‑service, ordinary privilege misuse, moderate information leakage, typical logic/design flaws, and other exploitable issues.

S3 (Low) : Internal XSS/CSRF/URL redirects that cannot directly obtain sensitive data, minor information leaks (path info, svn info, phpinfo, exception details), hard‑to‑exploit but potentially risky issues (self‑XSS), weak passwords on non‑critical services.

Special Cases for Vulnerability Levels

The definition of a critical (S0) vulnerability should be reviewed semi‑annually and redefined as needed.

Third‑party software vulnerabilities are treated as S3 by default unless they are severely harmful (treated as S2) or become externally disclosed (treated as S1 if no severe impact).

Information leaks (e.g., status leaks, test code exposure) default to S3; they are upgraded to S1 only when they expose C3, C4, B3, or B4 level information.

Port leaks are classified as S2.

In daily environments, internal system vulnerabilities that cannot be directly exploited by external parties are uniformly defined as S3.