SFTPGo is an open source, event-driven file transfer solution. From 2.2.0 until 2.7.3, the inline query parameter on browsable-share file downloads and authenticated user-file downloads suppresses Content-Disposition: attachment, allowing an attacker-controlled HTML file stored in a share or home directory to be served as text/html in the SFTPGo web origin. An attacker who can place the file can send a crafted link to a victim, and opening that link executes the stored content in the victim's browser context. Exploitation requires social engineering and suitable share or shared-folder access, while HttpOnly session cookies limit direct cookie theft. This issue is fixed in version 2.7.3.

Affected: Go: github.com/drakkan/sftpgo/v2

## Summary

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).

## Impact

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.

## Patches

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.