CVE-2026-77815

This is a symlink-enabling path traversal vulnerability, and the root cause is more subtle than a simple API misuse. The path containment check uses os.path.normpath, which normalizes path strings but does not resolve symbolic links. An attacker can place a symlink in a scanned directory pointing to sensitive files outside the intended boundary — the normpath call will produce a clean path string that passes the containment check, but the resolved filesystem path will point anywhere the symlink directs. The vulnerability activates only in networked deployments — specifically when the share, ngrok, listen, or server_name flags are set at startup. This is not an edge case; these are the default configurations for any production deployment where the WebUI needs to be accessible. An attacker doesn't need local access; they can probe the tool over the network, upload a symlink through the normal interface, and read arbitrary files the process can access. The fix replaces normpath with os.path.realpath, which resolves symlinks before comparison. This is correct, but it addresses only the symptom. Audit the rest of the codebase for other normpath calls in security-sensitive path operations — any path string comparison that controls access or determines where file operations occur should use realpath. Consider creating a dedicated path containment utility that always resolves symlinks, making the secure pattern the path of least resistance for future code. Without that structural fix, every future path check carries the same hidden risk. This vulnerability class has a two-decade history across web servers and file serving tools; the pattern will recur if the codebase doesn't build guardrails against it.

Reviewed through automated stages and approved by a human before publication.