<?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-10-02T22:49:59.669668+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-77637</id>
    <title>fkie_cve-2026-77637</title>
    <updated>2026-10-02T22:49:59.686704+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Cloudreve is a self-hosted file management and sharing system. Prior to 4.18.0, tool.GET("wopi") and tool.POST("mail") in routers/router.go inherit ScopeAdminRead but omit the RequiredScopes(types.ScopeAdminWrite) middleware applied to neighboring state-changing admin tool routes. An OAuth application or API key limited to Admin.Read can therefore probe configured WOPI service endpoints and send arbitrary test email through the server SMTP configuration, exceeding the token's intended read-only authorization boundary. This issue is fixed in version 4.18.0.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-77637"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-w89x-c962-c44g</id>
    <title>GHSA-w89x-c962-c44g — Cloudreve: Privilege Scope Bypass: State-Mutating Admin Operations Accessible via Read-Only OAuth Scope</title>
    <updated>2026-10-02T22:49:59.686802+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/cloudreve/Cloudreve/v4</p>
<p>### Summary
There is a privilege scope bypass in Cloudreve's admin API where two endpoints that mutate server state are missing the write-scope enforcement that their neighboring endpoints correctly apply. Specifically, the WOPI configuration fetch endpoint and the SMTP test/mail endpoint can both be triggered by an OAuth token that only has Admin.Read authorization — no Admin.Write needed. This breaks the intended OAuth scope boundary in a way that's subtle enough to have slipped through but meaningful enough to matter in a real deployment.</p>
<p>### Details
The root cause is an inconsistency in how the admin tool routes are wired up in `routers/router.go`. The admin route group sets a baseline of `ScopeAdminRead` for everything underneath it (around line 868), and most write-capable endpoints inside the `tool` sub-group correctly layer on an additional `RequiredScopes(types.ScopeAdminWrite)` check on top of that. For example, the thumbnail executable setter (line 929) and the entity URL cache deletion (line 937) both do this properly.</p>
<p>The two endpoints that don't follow this pattern are `tool.GET('wopi')` (line 925) and `tool.POST('mail')` (line 933). Despite `POST /mail` clearly triggering an outbound email and `GET /wopi` fetching or probing WOPI service connectivity, neither has the `ScopeAdminWrite` guard. What that means in practice is that any OAuth application granted only Admin.Read — a scope that should be limited to inspecting configuration, not changing anything — c…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-w89x-c962-c44g"/>
  </entry>
</feed>
