<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-03T02:22:14.617899+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/euvd-2026-330407</id>
    <title>EUVD-2026-330407</title>
    <updated>2026-10-03T02:22:14.621135+00:00</updated>
    <content>EUVD-2026-330407</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-330407"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-52812</id>
    <title>fkie_cve-2026-52812</title>
    <updated>2026-10-03T02:22:14.621177+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Gogs is an open source self-hosted Git service. Prior to 0.14.3, Git LFS storage is content-addressed by OID alone (&lt;LFS-root&gt;/&lt;oid[0]&gt;/&lt;oid[1]&gt;/&lt;oid&gt;) but per-repo authorization lives in the lfs_object table keyed (repo_id, oid). serveUpload skips re-uploading when the OID file already exists on disk and inserts a new (repo_id, oid) row pointing at it without verifying the request body hashes to the OID being claimed. Any user with write access to one repo can bind their repo to an OID owned by a private repo and download the original bytes via their own download endpoint. This vulnerability is fixed in 0.14.3.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-52812"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-6p9m-q3jp-47h4</id>
    <title>GHSA-6p9m-q3jp-47h4 — Gogs: LFS dedupe path leaks private repo content across tenants</title>
    <updated>2026-10-03T02:22:14.621229+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: gogs.io/gogs</p>
<p>Summary</p>
<p>Git LFS storage is content-addressed by OID alone (`&lt;LFS-root&gt;/&lt;oid[0]&gt;/&lt;oid[1]&gt;/&lt;oid&gt;`) but per-repo authorization lives in the `lfs_object` table keyed `(repo_id, oid)`. `serveUpload` skips re-uploading when the OID file already exists on disk and inserts a new `(repo_id, oid)` row pointing at it **without verifying the request body hashes to the OID being claimed**. Any user with write access to one repo can bind their repo to an OID owned by a private repo and download the original bytes via their own download endpoint.</p>
<p>Details</p>
<p>Dedupe shortcut at `internal/lfsx/storage.go:79-82`:</p>
<p>```go
if fi, err := os.Stat(fpath); err == nil {
    _, _ = io.Copy(io.Discard, rc)
    return fi.Size(), nil          // ← returns success with no hash check
}
```</p>
<p>Hash verification at `internal/lfsx/storage.go:106-108` only runs in the *new-file* branch — the dedupe path returns earlier.</p>
<p>`serveUpload` (`internal/route/lfs/basic.go:78-114`) trusts that success and inserts the per-repo binding:</p>
<p>```go
_, err := h.store.GetLFSObjectByOID(c.Req.Context(), repo.ID, oid)   // per-repo
if err == nil { /* already linked, drain &amp; return 200 */ }
written, err := s.Upload(oid, c.Req.Request.Body)
err = h.store.CreateLFSObject(c.Req.Context(), repo.ID, oid, written, s.Storage())
```</p>
<p>`CreateLFSObject` is an unconditional `INSERT` on `(repo_id, oid)` with no check that the OID is referenced by the requesting repo's git history.</p>
<p>`serveDownload` at `internal/route/lfs/basic.go:42-72` only cons…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-6p9m-q3jp-47h4"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2013</id>
    <title>WID-SEC-W-2026-2013 — Gogs: Mehrere Schwachstellen</title>
    <updated>2026-10-03T02:22:14.621345+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer kann mehrere Schwachstellen in Gogs ausnutzen, um erweiterte Berechtigungen zu erlangen, beliebigen Code auszuführen – sogar mit erweiterten Berechtigungen, was zur vollständigen Kontrolle über das System führen kann –, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren, Cross-Site-Scripting-Angriffe durchzuführen, Benutzer auf bösartige Websites umzuleiten oder einen Denial-of-Service-Zustand zu verursachen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2013"/>
  </entry>
</feed>
