<?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-30T12:03:22.145721+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-50105</id>
    <title>fkie_cve-2026-50105</title>
    <updated>2026-09-30T12:03:22.150315+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>RSS/Atom feed handlers bypass API-token scope &amp; public-only confinement (incomplete fix of #37698)</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-50105"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-6cqf-375w-639g</id>
    <title>GHSA-6cqf-375w-639g — Gitea: RSS/Atom feed handlers bypass API-token scope &amp; public-only confinement (incomplete fix of #37698)</title>
    <updated>2026-09-30T12:03:22.150402+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: code.gitea.io/gitea</p>
<p>### Summary</p>
<p>Gitea's RSS/Atom feed handlers accept API-token Basic auth but perform **no token-scope or
public-only enforcement**. A personal access token that is correctly blocked (HTTP 403) from a
private repository on `/raw`, `/media`, `/archive`, and `/releases/download/...` — because it is
marked *public-only* or lacks the `repository` scope category — still returns that repository's
private content through the feed routes. This is a token-confinement bypass and appears to be an
incomplete fix of #37698, which added that scope enforcement to the download handlers but not to the
sibling feed handlers.</p>
<p>This is **not** a cross-user access bug: the requesting account must still legitimately have repo
read access (`RepoAssignment` + `reqUnitCodeReader` are enforced). What is bypassed is the guarantee
that a *confined* token cannot reach private content — which is exactly the property #37698 was
shipped to provide for downloads, and which matters when such a token is handed to a third-party
service/CI, leaked, or used in a lower-trust integration.</p>
<p>### Details</p>
<p>#37698 added `context.CheckTokenScopes` / `CheckRepoScopedToken`
(`services/context/permission.go`) to the raw / media / archive / attachment download handlers, so a
public-only or wrong-scope-category token cannot read private-repo content even when the owning user
otherwise has access.</p>
<p>The feed handlers are registered with `webAuth.AllowBasic` (so they accept token Basic auth) but call
no scope / public-only check.…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-6cqf-375w-639g"/>
  </entry>
</feed>
