CVE-2026-63188 in Logto
Summary
by MITRE • 08/19/2026
Logto is the modern, open-source auth infrastructure for SaaS and AI apps. Prior to 0.3.9, the Logto Tunnel npm package enabled createStaticFileProxy from packages/tunnel/src/commands/tunnel/index.ts and passed request.url from static asset requests through packages/tunnel/src/commands/tunnel/utils.ts using path.join(staticPath, request.url) and then fs.open(requestPath, "r") without URL normalization or a containment check. When --experience-path was enabled and the tunnel port was reachable, an unauthenticated requester could send a path containing ../ to createStaticFileProxy and read files outside the configured static directory that were readable by the logto-tunnel process. The service used server.listen(port), which could expose the tunnel to other hosts depending on the platform and deployment. This issue is fixed in version 0.3.9.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in Logto versions prior to 0.3.9 constitutes a critical path traversal flaw within the logto-tunnel npm package, specifically affecting the static file proxy functionality. The core technical deficiency lies in how the application handles incoming request URLs when serving static assets. Upon receiving a request, the system utilizes the path.join method to concatenate a configured base directory with the raw request.url parameter without performing any URL normalization or sanitization checks. This architectural oversight allows an attacker to inject relative path sequences, such as ../, into the request URI. Because path.join does not inherently prevent traversal outside of its root context when given absolute-like segments or excessive dot-dot notation in certain Node.js versions and configurations, this results in the file system resolving a target path that resides outside the intended static directory boundary.
The operational impact of this vulnerability is severe, as it enables unauthenticated remote attackers to read arbitrary files from the host operating system where the logto-tunnel service is executing. By crafting specific HTTP requests containing path traversal sequences, an attacker can access sensitive configuration files, source code, environment variables, or other data stored on the server that has file permissions readable by the process running Logto. This capability effectively bypasses all intended isolation mechanisms designed to restrict web servers from accessing non-public resources. The severity is further amplified by the default network binding behavior of Node.js applications; when using server.listen with a specified port without explicitly binding to localhost, the service may become accessible over external networks depending on the deployment environment and firewall rules. Consequently, any host that can reach the tunnel port becomes susceptible to this exploitation vector if the vulnerability remains unpatched.
From a classification perspective, this flaw aligns directly with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, commonly known as path traversal or directory traversal. The attack mechanism also maps to MITRE ATT&CK technique T1083: File and Directory Discovery, where adversaries probe the file system to gather information for further exploitation. In many cases, such vulnerabilities are exacerbated by CWE-20: Improper Input Validation, as the application fails to validate or sanitize user-supplied input before using it in file system operations. The lack of containment checks means that even if the static path is correctly defined, the dynamic construction of the final file path allows for boundary violations that compromise data confidentiality and integrity.
Mitigation strategies primarily involve upgrading to Logto version 0.3.9 or later, where this issue has been resolved through improved input validation and secure path handling mechanisms. In environments where immediate patching is not feasible, defensive measures should include restricting network access to the tunnel port via firewall rules so that it is only accessible from trusted internal networks rather than exposed publicly. Additionally, running the logto-tunnel process with minimal file system permissions can limit the scope of data exposure if an attack were successful. It is also advisable to ensure that Node.js applications explicitly bind to localhost or specific private IP addresses unless external access is strictly required and secured through additional authentication layers such as reverse proxy configurations with strict access controls.