GHSA-C2M8-H5V5-343R
GHSA-C2M8-H5V5-343R: Path Traversal via Improper Link Resolution in Tornado StaticFileHandler
Amit Schendel
Senior Security ResearcherOct 1, 2026·4 min read·5 visits
Executive Summary (TL;DR)
Tornado's StaticFileHandler prior to 6.5.9 is vulnerable to path traversal and arbitrary file disclosure. By performing lexical validation instead of physical path resolution, the application serves files targeted by symbolic links that point outside the static root.
A path traversal and arbitrary file disclosure vulnerability exists in Tornado's StaticFileHandler. In versions prior to 6.5.9, the handler follows symbolic links that point outside of the configured root static directory. This behavior occurs because the handler performs lexical path validation rather than physical filesystem resolution, allowing unauthenticated remote attackers to read arbitrary files if they can access or control symbolic links within the served static root.
Vulnerability Overview
The affected component is tornado.web.StaticFileHandler, which serves static files from a configured root directory in web applications. It exposes an attack surface by receiving client-controlled path inputs and resolving them against the local filesystem.
The vulnerability is classified as CWE-59 (Improper Link Resolution Before File Access) and CWE-22 (Path Traversal). In vulnerable configurations, if an attacker can access or create a symbolic link inside the configured static root directory, they can traverse boundaries. This allows unauthorized retrieval of arbitrary files from the server's local filesystem.
Root Cause Analysis
The core of the vulnerability lies in the use of lexical resolution instead of physical resolution during path validation. The affected handler validated the absolute path using os.path.abspath, which performs pure string manipulation. Lexical resolution does not query the filesystem to determine whether path elements are symbolic links.
Because os.path.abspath validated that the path was lexically inside the configured root directory, the boundary check succeeded. However, when the file was subsequently opened, the operating system's filesystem resolved the physical symbolic link. This redirection allowed access to files located entirely outside the designated static root directory.
Furthermore, deferring physical resolution created a potential "existence oracle" vulnerability. If physical path resolution occurs after checking if a directory exists, requesting an out-of-bounds directory could cause a redirect (HTTP 301). Requesting a non-existent directory would return a standard error (HTTP 403 or 404), revealing the host layout to the attacker.
Code-Level Patch Analysis
The fix in version 6.5.9 addresses the bug by introducing an explicit physical resolution step during validation. The StaticFileHandler was updated with a new initializer argument named allowed_symlink_directory. This argument defaults to the configured base path but can be expanded manually.
The validation workflow first runs the lexical check, which remains a low-overhead defense against standard relative path traversal attempts. Following this, the method calls _resolve_symlink_target to obtain the physical canonical path using os.path.realpath. This canonical path is verified to ensure it begins with the allowed symlink directory path.
Additionally, the patch replaces multiple filesystem checks with a single-pass os.stat call. This optimization binds the validated path details to a static local state. By preventing multiple lookups during header generation, the code mitigates potential Time of Check to Time of Use (TOCTOU) race conditions.
Exploitation Methodology
Exploitation of this vulnerability requires that a symbolic link pointing outside the static root directory exists inside the static folder. This condition typically occurs in shared multi-tenant filesystems, repositories containing checked-in symlinks, or applications allowing custom file uploads.
An attacker executes the payload by requesting the symlink or a subpath of the symlinked directory over HTTP. The StaticFileHandler receives the path segment and matches it against its routing table. Because the requested URI does not contain direct lexical traversal characters like .., the initial validation steps are bypassed.
When the request finishes processing, the physical file is read and returned to the client. This exposes sensitive system files such as database configurations, application source code, or system credentials.
Remediation and Defensive Mitigations
The primary remediation strategy is upgrading the tornado package to version 6.5.9 or higher. This upgrade implements physical symlink target validation by default. If symlinks are required, administrators must configure allowed_symlink_directory explicitly to safe boundaries.
Operational workarounds include structuring filesystems to disallow symbolic links in directories handled by the static handler. Security teams should also filter user-uploaded archives to block the extraction of symbolic links. Running the application inside an isolated read-only container also restricts filesystem access.
Fix Analysis (2)
Technical Appendix
CVSS Score
7.5/ 10
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:NAffected Systems
Tornado web framework StaticFileHandler deployments
Affected Versions Detail
| Product | Affected Versions | Fixed Version |
|---|---|---|
Tornado Tornadoweb | < 6.5.9 | 6.5.9 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-59, CWE-22 |
| Attack Vector | Network |
| CVSS Score | 7.5 (High) |
| Impact | Arbitrary File Disclosure |
| Exploit Status | PoC / Functional (via unit tests) |
| KEV Status | Not listed |
MITRE ATT&CK Mapping
CWE-59
Improper Link Resolution Before File Access ('Link Following')
The application attempts to access a file based on a filename, but it does not properly validate whether that file is a symbolic link or shortcut that redirects the access to an unintended resource.
