The inline query parameter on the browsable-share file download and on the authenticated user file download suppressed Content-Disposition: attachment, so an HTML file stored in a share or home directory could be served as text/html and execute in SFTPGo's web origin (stored XSS).
Low. Exploitation requires the attacker to place the file and a victim to open the crafted link — a URL the WebClient never generates, so it requires social engineering — and the practical conditions are narrow:
It is a genuine trust-boundary violation (SFTPGo emits attacker-controlled content as active HTML in its own origin), hence an advisory, but the constrained preconditions and the HttpOnly mitigation keep it Low.
Upgrade to v2.7.3. These endpoints now always respond with Content-Disposition: attachment; the inline parameter has been removed. See the fix commit for the full technical rationale.
{
"github_reviewed_at": "2026-07-02T19:09:30Z",
"nvd_published_at": null,
"github_reviewed": true,
"cwe_ids": [
"CWE-79"
],
"severity": "LOW"
}