SFTPGo has stored XSS via inline parameter on public shares and user file download

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:

• Session cookies are HttpOnly, so the cookie cannot be read by the injected script.
• Authenticated shares set their own session cookie, which overwrites the victim's WebClient cookie, no account pivot. The realistic case is a public share, or a folder shared between distinct users combined with targeted social engineering.

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.