<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 04:18:21 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-49245</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-49245</link>
      <description>&lt;p&gt;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&amp;#39;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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&amp;#39;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-49245</guid>
    </item>
    <item>
      <title>GHSA-3vcg-pv95-pq54 — SFTPGo has stored XSS via inline parameter on public shares and user file download</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-3vcg-pv95-pq54</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/drakkan/sftpgo/v2&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;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&amp;#39;s web origin (stored XSS).&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;p&gt;- 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&amp;#39;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;## Patches&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/drakkan/sftpgo/v2&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;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&amp;#39;s web origin (stored XSS).&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;p&gt;- 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&amp;#39;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;## Patches&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-3vcg-pv95-pq54</guid>
    </item>
  </channel>
</rss>
