[BUG] static_route_exts / static_route allow directory traversal via fname path segments

[Mefisto04]

Describe the bug

static_route_exts() and static_route() build file paths by string concatenation without normalizing or constraining fname to stay under static_path:

# fasthtml/core.py
FileResponse(f'{static_path}/{fname}.{ext}')   # static_route_exts
FileResponse(f'{static_path}/{fname}{ext}')    # static_route

Because {fname:path} can contain .. segments, a request may escape the intended static directory if the target file exists on disk.

Minimal Reproducible Example

import os, tempfile
from starlette.testclient import TestClient
from fasthtml.common import fast_app

tmpdir = tempfile.mkdtemp()
parent = os.path.dirname(tmpdir)
open(os.path.join(parent, "secret.txt"), "w").write("LEAKED")

app, rt = fast_app(static_path=tmpdir)
client = TestClient(app)
resp = client.get("/../secret.txt")
print(resp.status_code, resp.text)

Expected behavior

Static handlers should only serve files whose resolved path is inside static_path. Paths with .. should return 404.

Actual behavior

FileResponse is built with a path outside static_path. _resp() only checks os.path.exists(resp.path) without verifying the path stays within the static root.

Suggested fix

Resolve with Path(static_path, fname).resolve() and verify resolved.is_relative_to(Path(static_path).resolve()).

Environment Information

• fasthtml version: 0.14.x (main)
• Python: 3.11+

Confirmation

• I have read the FAQ (https://docs.fastht.ml/explains/faq.html)
• I have provided a minimal reproducible example
• I understand that this is a volunteer open source project with no commercial support.

[lackas]

We can reproduce this on 0.14.11, and I want to make sure the severity is on the radar: this is unauthenticated arbitrary file read, so we'd rate it critical.

Reproduced: a single-level .. (raw, or single-percent-encoded %2e%2e) escapes static_path. /%2e%2e/secret.md returns a file that exists outside the static directory, and /%2e%2e/%2e%2e/… walks further up. Double-encoding (%252e) is not decoded, so it's specifically single-decoded ...

Why critical — what is actually exposed:

• Via static_route_exts (what fast_app() registers by default), any file the worker can read whose name ends in one of the ~60 static extensions is reachable. That set already includes the things you least want served: database dumps and archives (.gz, .zip, .tar, .tgz, .bz2), data exports (.csv, .xls, .xlsx, .doc), and config/secrets (.yaml, .yml, .xml, and .env.txt-style names). We verified an existing sibling file outside static_path is served, not merely a 404.
• Via a bare static_route() (ext='') there is no extension gate at all — we confirmed /%2e%2e/%2e%2e/etc/passwd returns the file, and likewise any .json/secret/config path.
• Blast radius: in a container it's the whole rootfs plus any mounted volumes — which is exactly where app data and backups usually live; on a bare-metal/venv deploy it's every file the app user can read.

Related work:

• [BUG] static_path defaults to the app root ('.'), serving config, data and backups over HTTP #918 — the adjacent issue that the default static_path='.' serves the app root even without traversal. Separate root cause, worth its own fix.
• [PR] Prevent path traversal in static file routes (#912) #919 — a PR fixing this traversal issue: resolve the requested path against static_path and return 404 if it escapes, matching Starlette's own StaticFiles containment (which also closes symlink escapes). Includes a test that fails without the patch and passes with it.

Happy to iterate on the PR in whatever direction you prefer.