CVE-2026-63188

The CVSS 8.7 rating for this path traversal in Logto Tunnel obscures more than it reveals. The vulnerability itself is straightforward — no URL normalization, no containment check, classic '../' bypass in the static file handler. What the CVSS doesn't capture is that exploitability depends entirely on deployment-specific network exposure the advisory refuses to characterize. If the tunnel binds to localhost only (the common default for development utilities), an attacker needs local access or a separate vulnerability to reach it. If it binds to 0.0.0.0, you're in a different severity tier entirely. Check your binding configuration before assuming the CVSS applies to your deployment. The more important question the CVSS misses: what can an attacker actually read? Logto is authentication infrastructure — the tunnel process likely runs with the same OS-level privileges as the core auth service. An attacker with arbitrary file read could access configuration files, environment artifacts, or session data that enables lateral movement into the auth layer itself. We're not just measuring a file read vulnerability; we're measuring a potential key extraction vector that could compromise signing keys, OAuth secrets, or database passwords. The EPSS of 0.00441 reflects current exploitation probability — what honeypots have seen — not what an attacker could do if they hit a misconfigured deployment. Two things to verify immediately: First, determine what your Logto Tunnel instance binds to by default in versions before 0.3.9 — that documentation gap is itself a red flag. Second, audit whether credential material (signing keys, OAuth secrets, database credentials) would be readable by the tunnel process. If the tunnel runs with auth-layer privileges, this isn't a local file disclosure — it's a potential authentication layer compromise, and your patching priority should reflect that.

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