Category 5 Evaluation Criteria

When evaluating whether a Potential Category 5 (i.e., CVSS 10) vulnerability may be classified as such, we assess it against three key criteria.

Is there a direct, credible path to Remote Code Execution (RCE)?
Is the vulnerability practically exploitable within a Minimally Viable Security Posture (MVSP)?
Is the affected package a library or dependency integrated into an application, rather than a standalone application package?

In practice, many vulnerabilities will not meet these criteria and, even with a highly conservative risk profile, they will not exceed Category 4.

Criteria 1: Remote Code Execution (RCE)

RCE represents full compromise of the target system, allowing an attacker to execute arbitrary commands with the privileges of the application.

We require that RCE be achievable without relying on unrealistic assumptions or non-standard configurations such as:

non-standard or insecure configurations where isolation or hardening options were disabled
optional or rarely enabled features being active
complex multi-step exploit chains
user interaction or manual intervention
debug, development, or test configurations exposed in production
unrealistic attacker control over multiple independent components

Sandbox Escape Vulnerabilities

In addition, we do not consider "sandbox escape" vulnerabilities to be eligible for Category 5 classification, as they inherently assume the application already allows execution of attacker-controlled code and treat the sandbox as the primary security boundary. Such vulnerabilities will share the following analysis:

This vulnerability is classified as a "sandbox escape" and may allow an attacker to bypass the library's intended boundaries or execution restrictions. However, under an MVSP with isolated deployments, this is best viewed as a limitation of the sandbox model rather than a practically severe vulnerability.

Criteria 2: Minimally Viable Security Posture (MVSP)

Our evaluation assumes that applications operate within a Minimally Viable Security Posture (MVSP). Without this baseline, systems are already susceptible to trivial compromise, such as weak credentials or unauthenticated access, which are far more likely attack vectors and make vulnerability severity distinctions less meaningful.

Under MVSP, we assume the presence of the following baseline controls:

Public Bot / Rate Limiting - basic protections, such as request throttling or load balancer filtering, are in place to reduce automated exploitation
Application Isolation - execution occurs within containers, hosts, or VMs with restricted filesystem access and limited system privileges
App Monitoring / Recovery - abnormal activity is monitored, with rapid restart and recovery capabilities
Offsite / Long-term Backup - regular backups to separate storage enable recovery from loss or corruption
Security Configuration in the Application - no insecure defaults or unnecessary dangerous functionality

Vulnerabilities that are only exploitable in the absence of these baseline controls are not considered Category 5 in practice.

Criteria 3: Library or Dependency Package

The Package Vulnerability Remediation Scale (PVRS) is intended for OSS libraries that are integrated into an application. PVRS Categories provide actionable, context-specific guidance to balance the risks of upgrading dependencies against real-world exploitation risks.

Many standalone tools, applications, and servers are distributed through package managers such as npm, Rubygems, and NuGet. These programs (such as n8n, typescript, sidekiq, Packet) are often used in development and build workflows, but are rarely (if ever) integrated into the runtime logic of an application.

When exploitation depends on the package being operated as a standalone application, invoked manually as a CLI tool, or exposed through a separate service configuration, the vulnerability is not considered Category 5.

Such vulnerabilities will share the following analysis:

This vulnerability affects a package that is primarily operated as a standalone application, service, CLI tool, or workflow system rather than integrated as a library or dependency within application runtime logic. While exploitation may have severe impact in deployments where that standalone package is exposed or attacker-accessible, it does not create a broadly applicable compromise path for consuming applications.