GHSA-3VCG-PV95-PQ54
Vulnerability from github – Published: 2026-07-02 19:09 – Updated: 2026-07-02 19:09Summary
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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.7.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/drakkan/sftpgo/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.7.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-49245"
],
"database_specific": {
"cwe_ids": [
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T19:09:30Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "## Summary\n\nThe 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\u0027s web origin (stored XSS).\n\n## Impact\n\nLow. Exploitation requires the attacker to place the file and a victim to open the crafted link \u2014 a URL the WebClient never generates, so it requires social engineering \u2014 and the practical conditions are narrow:\n\n- Session cookies are HttpOnly, so the cookie cannot be read by the injected script.\n- Authenticated shares set their own session cookie, which overwrites the victim\u0027s WebClient cookie, no account pivot. The realistic case is a public share, or a folder shared between distinct users combined with targeted social engineering.\n\nIt 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.\n\n## Patches\n\nUpgrade 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.",
"id": "GHSA-3vcg-pv95-pq54",
"modified": "2026-07-02T19:09:30Z",
"published": "2026-07-02T19:09:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/drakkan/sftpgo/security/advisories/GHSA-3vcg-pv95-pq54"
},
{
"type": "PACKAGE",
"url": "https://github.com/drakkan/sftpgo"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "SFTPGo has stored XSS via inline parameter on public shares and user file download"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.