<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-29T19:56:13.940639+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-50139</id>
    <title>fkie_cve-2026-50139</title>
    <updated>2026-09-29T19:56:13.966886+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>goshs is a SimpleHTTPServer written in Go. Prior to version 2.1.0, `ShareHandler` reads the share token's `DownloadLimit` under `RLock`, releases the lock, serves the file, then re-acquires the lock to increment the counter. Concurrent requests all read the same `Downloaded`/`DownloadLimit` snapshot, all pass the check, and all are served — exceeding the operator's intended cap. Version 2.1.0 patches the issue.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-50139"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-j48m-h7xq-2xpj</id>
    <title>GHSA-j48m-h7xq-2xpj — goshs: Share-link ?token=… redemption races past download limit</title>
    <updated>2026-09-29T19:56:13.966997+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: goshs.de/goshs/v2</p>
<p># Share-link `?token=…` redemption races past download limit</p>
<p>**Ecosystem:** Go
**Package:** `goshs.de/goshs/v2` (`github.com/patrickhener/goshs`)
**Affected:** `&lt;= v2.0.9` (every release that shipped the share-link feature)</p>
<p>## Summary</p>
<p>`ShareHandler` reads the share token's `DownloadLimit` under `RLock`, releases the lock, serves the file, then re-acquires the lock to increment the counter. Concurrent requests all read the same `Downloaded`/`DownloadLimit` snapshot, all pass the check, and all are served — exceeding the operator's intended cap.</p>
<p>## Details</p>
<p>[`httpserver/handler.go:968-1018`](https://github.com/patrickhener/goshs/blob/v2.0.9/httpserver/handler.go#L968-L1018):</p>
<p>```go
fs.sharedLinksMu.RLock()
entry, ok := fs.SharedLinks[token]
fs.sharedLinksMu.RUnlock()                       // &lt;-- released here</p>
<p>if entry.DownloadLimit &gt; 0 || entry.DownloadLimit == -1 {
    // ...serve file...                          // &lt;-- whole transfer happens unlocked
}</p>
<p>fs.sharedLinksMu.Lock()                          // &lt;-- re-acquired only now
current.Downloaded++
if current.Downloaded &gt;= current.DownloadLimit { delete(fs.SharedLinks, token) }
fs.sharedLinksMu.Unlock()
```</p>
<p>Between line 978 (`RUnlock`) and line 1008 (`Lock`), any number of goroutines can interleave and each observes the same pre-increment limit.</p>
<p>## Proof of concept</p>
<p>```bash
goshs -p 18000 -d /tmp/r -b admin:pw &amp;
echo data &gt; /tmp/r/f.txt</p>
<p># operator issues a one-shot share
SHARE=$(curl -su admin:pw "http://localhost:1…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-j48m-h7xq-2xpj"/>
  </entry>
</feed>
