CVE-2026-50139

MEDIUMPre-NVD 5.95.9
EchelonGraph scoreLOW confidence

This medium-severity CVE scores 5.9 under the CNA's CVSS (NVD's own analysis pending). EPSS exploit-prediction score not yet available (the EPSS model rescores nightly; freshly-published CVEs typically appear within 48 hours). GitHub Security Advisory data not yet ingested — confidence will rise once GHSA publishes (typical lag: hours to days for open-source ecosystem CVEs; never for infrastructure-only CVEs).

Triggered by: NVD CVSS baseline
Sources: cna:github_m
5.9
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • Lower severity and no public exploit yet
CISA-KEV: Not listedEPSS: CVSS: 5.9Exploit: NoneExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

goshs: Share-link ?token=… redemption races past download limit

Share-link ?token=… redemption races past download limit

Ecosystem: Go Package: goshs.de/goshs/v2 (github.com/patrickhener/goshs) Affected: <= v2.0.9 (every release that shipped the share-link feature)

Summary

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.

Details

httpserver/handler.go:968-1018:

fs.sharedLinksMu.RLock()
entry, ok := fs.SharedLinks[token]
fs.sharedLinksMu.RUnlock()                       // <-- released here

if entry.DownloadLimit > 0 || entry.DownloadLimit == -1 { // ...serve file... // <-- whole transfer happens unlocked }

fs.sharedLinksMu.Lock() // <-- re-acquired only now current.Downloaded++ if current.Downloaded >= current.DownloadLimit { delete(fs.SharedLinks, token) } fs.sharedLinksMu.Unlock()

Between line 978 (RUnlock) and line 1008 (Lock), any number of goroutines can interleave and each observes the same pre-increment limit.

Proof of concept

goshs -p 18000 -d /tmp/r -b admin:pw &
echo data > /tmp/r/f.txt

operator issues a one-shot share

SHARE=$(curl -su admin:pw "http://localhost:18000/f.txt?share&limit=1") TK=$(echo "$SHARE" | sed -n 's/.*token=\([^"]*\)".*/\1/p')

attacker races two redemptions

curl -so /dev/null -w "%{http_code}\n" "http://localhost:18000/?token=$TK" & \ curl -so /dev/null -w "%{http_code}\n" "http://localhost:18000/?token=$TK" & \ wait

observed: 200 / 200 (both succeed) -> limit=1 redeemed twice

Reproduced 5/5 times in a row on a 2026-era M-series Mac during verification.

Impact

A "single-use" share intended to deliver a one-shot secret can be redeemed N times by N concurrent clients. Combined with any token-leak vector (mail forwarding, browser history, intercepted link, etc.) this multiplies the exfiltration window.

Suggested fix

Reserve under the write lock *before* serving — refund only if the serve fails:

fs.sharedLinksMu.Lock()
entry, ok := fs.SharedLinks[token]
if !ok || time.Now().After(entry.Expires) ||
   (entry.DownloadLimit != -1 && entry.Downloaded >= entry.DownloadLimit) {
    fs.sharedLinksMu.Unlock(); http.NotFound(w, r); return
}
entry.Downloaded++
if entry.DownloadLimit != -1 && entry.Downloaded >= entry.DownloadLimit {
    delete(fs.SharedLinks, token)
} else {
    fs.SharedLinks[token] = entry
}
fs.sharedLinksMu.Unlock()
// ...serve...

Add a regression test that races two requests against a limit=1 token and asserts exactly one 200.

Reporter: Nishant Verma. Reproduced against goshs v2.0.9 (commit 8fc1e91) on 2026-05-27.

CVSS v3
5.9
EG Score
5.9(low)
EPSS
KEV
Not listed

Published

July 1, 2026

Last Modified

July 1, 2026

Vendor Advisories for CVE-2026-50139(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 5× in last 7d / 5× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-07-06 04:33 UTCEG score recompute
  2. 2026-07-05 02:55 UTCEG score recompute
  3. 2026-07-04 01:17 UTCEG score recompute
  4. 2026-07-02 23:39 UTCEG score recompute
  5. 2026-07-01 22:02 UTCEG score recompute

Frequently asked(4)

What is CVE-2026-50139?
CVE-2026-50139 is a medium vulnerability published on July 1, 2026. goshs: Share-link ?token=… redemption races past download limit Share-link ?token=… redemption races past download limit Ecosystem: Go Package: goshs.de/goshs/v2 (github.com/patrickhener/goshs) Affected: <= v2.0.9 (every release that shipped the share-link feature) Summary ShareHandler reads the…
When was CVE-2026-50139 disclosed?
CVE-2026-50139 was first published in the National Vulnerability Database on July 1, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
What is the CVSS score of CVE-2026-50139?
CVE-2026-50139 has a CVSS v4.0 base score of 5.9 (CNA self-assessment; NVD's own analysis pending). The EG score is currently aggregating — additional source signals are being incorporated as they become available..
How do I remediate CVE-2026-50139?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-50139, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-50139

Explore →

Is Your Infrastructure Affected by CVE-2026-50139?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.