CVE-2026-30848: Path Traversal Vulnerability in Parse Server PagesRouter

Parse Server utilizes the PagesRouter component to serve static files associated with system pages, such as email verification and password reset screens. This component processes incoming HTTP requests and maps them to physical files residing within a configured pagesPath directory. A vulnerability within this routing logic permits path traversal, classified under CWE-22, enabling unauthenticated read operations.

The core issue manifests when the router validates whether a requested file path falls within the boundaries of the designated base directory. The validation mechanism relies on a standard string prefix comparison instead of a robust directory boundary evaluation. This design oversight exposes the system to unauthorized access outside the intended directory structure.

Exploitation requires specific conditions on the host filesystem. The target directory must share the exact string prefix as the configured pagesPath directory. When these prerequisites are met, an attacker can retrieve sensitive files located in sibling directories, bypassing the intended access controls and compromising data confidentiality.

The path validation flaw originates in src/Routers/PagesRouter.js, where the application sanitizes and verifies the requested file paths. The logic first applies path.normalize() to resolve any traversal sequences such as ../ or ./ within the input URL. After normalization, the resulting path is evaluated against the configured this.pagesPath variable.

The critical failure occurs during this boundary evaluation step. The code executes normalizedPath.startsWith(this.pagesPath) to confirm the file remains within the allowed directory tree. Because startsWith performs a strict string-level comparison without acknowledging directory separators, it fails to differentiate between a nested file and a sibling directory sharing the same prefix.

For example, if the application configures the base directory as /var/www/pages, the startsWith function validates any path beginning with that exact string. A request traversing to /var/www/pages-secret/config.json yields a normalized path that successfully passes the prefix check. The application processes the request, incorrectly assuming the target file resides within the approved pages directory.

The vulnerability exists within a specific conditional block in the PagesRouter class. The original implementation attempts to restrict file access by throwing an error if the normalized path does not begin with the allowed base path string.

// Vulnerable Implementation (src/Routers/PagesRouter.js)
const normalizedPath = path.normalize(filePath);
 
// Abort if the path is outside of the path directory scope
if (!normalizedPath.startsWith(this.pagesPath)) {
    throw errors.fileOutsideAllowedScope;
}

The patched implementation resolves this semantic gap by enforcing a strict directory boundary. The patch concatenates the platform-specific directory separator (path.sep) to the end of the allowed base path before executing the prefix comparison.

// Patched Implementation (src/Routers/PagesRouter.js)
const normalizedPath = path.normalize(filePath);
 
// Abort if the path is outside of the path directory scope
if (!normalizedPath.startsWith(this.pagesPath + path.sep)) {
    throw errors.fileOutsideAllowedScope;
}

This modification ensures that the validation logic requires the target path to exist strictly as a child of the base directory. By appending the separator, the check against /var/www/pages/ automatically rejects traversal attempts targeting /var/www/pages-secret/, mitigating the bypass technique.

Attackers exploit this vulnerability by dispatching crafted HTTP GET requests to the public-facing pages route, typically exposed under the /apps/ endpoint. The attack payload utilizes URL-encoded path traversal sequences, specifically %2e%2e%2f representing ../, to manipulate the file path resolution process.

A functional proof-of-concept requires the existence of a target directory adjacent to the configured pagesPath. If the application serves pages from a directory named pages, the attacker targets a sibling directory such as pages-secret. The corresponding HTTP request takes the form of GET /apps/%2e%2e%2fpages-secret%2fsecret.txt HTTP/1.1.

Upon receiving the request, the application normalizes the path, stripping the traversal sequences while resolving the absolute location. The resulting string is /path/to/pages-secret/secret.txt. Since this string begins with /path/to/pages, the vulnerable validation check succeeds. The server processes the file read operation and returns the contents of the target file in the HTTP response body.

The vulnerability enables unauthorized, unauthenticated retrieval of files stored on the underlying filesystem. This file read capability directly impacts system confidentiality by exposing potentially sensitive data. The CVSS 4.0 base score of 6.3 reflects the medium severity of this issue, governed primarily by the specific prerequisites required for successful exploitation.

The exploit scope is strictly limited to sibling directories that share the exact nomenclature prefix of the configured base directory. An attacker cannot arbitrarily traverse the entire filesystem to read files in standard locations such as /etc/passwd or /var/log/syslog unless the base directory configuration aligns with those paths. This constraint significantly reduces the overall impact radius.

Despite these limitations, the vulnerability poses a material risk in environments where configuration files, environment variables, or other sensitive application data reside adjacent to the static pages directory. The unauthenticated nature of the attack vector allows remote adversaries to systematically probe for predictable sibling directory names without requiring valid credentials.

System administrators must update Parse Server installations to the appropriate patched releases to permanently resolve this vulnerability. The official maintainers have published fixes in Parse Server version 8.6.8 for the 8.x release line and version 9.5.0-alpha.8 for the 9.x release line. Applying these updates replaces the vulnerable routing logic with the robust directory separator validation check.

In scenarios where immediate patching is unfeasible, administrators can deploy a configuration-based workaround. The vulnerability relies on the existence of sibling directories sharing the same prefix string. By renaming the configured pagesPath directory to a completely unique string, administrators eliminate the requisite filesystem conditions for the exploit.

Additionally, deploying a Web Application Firewall (WAF) rule to intercept and block incoming requests containing URL-encoded traversal sequences (%2e%2e%2f) offers an effective interim defense mechanism. This network-level mitigation prevents the malicious payloads from reaching the vulnerable application component.