<?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-04T21:32:40.026821+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-62323</id>
    <title>fkie_cve-2026-62323</title>
    <updated>2026-10-04T21:32:40.063940+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.17.0, ViewerSessionValidation uses only the session-id prefix of a WOPI access token and does not enforce the requested viewer action, allowing a malicious or compromised WOPI viewer with a view session to forge the token suffix and invoke WOPI write routes for the underlying file. This issue is fixed in version 4.17.0.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-62323"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-c3jm-gv5r-9wcp</id>
    <title>GHSA-c3jm-gv5r-9wcp — Cloudreve WOPI view sessions can write files and WOPI access token secret is ignored</title>
    <updated>2026-10-04T21:32:40.064075+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/cloudreve/Cloudreve/v4, Go: github.com/cloudreve/Cloudreve/v3</p>
<p>## Summary</p>
<p>Cloudreve WOPI access tokens are generated as `&lt;session-id&gt;.&lt;random-secret&gt;`, but the WOPI middleware validates only the session id prefix and never compares the supplied token to the stored token. In addition, a WOPI viewer session does not store or enforce the requested viewer action. A session created for a view or preview action can still call WOPI write routes if the underlying file is writable by the session user.</p>
<p>## Impact</p>
<p>A WOPI integration that is only expected to view a user's file can modify that file through the WOPI write endpoints. If the WOPI URL or session id leaks, the random token suffix does not protect the session because any suffix is accepted for an existing session id.</p>
<p>This affects deployments that configure WOPI viewers for user files. The attacker primitive is strongest when a malicious or compromised WOPI viewer receives a view-only URL and then writes content back to Cloudreve.</p>
<p>## Affected version</p>
<p>Verified in source and runtime on latest master commit `ba2e870bbd17f1918dd2321de861e453f696d6a3` and latest observed tag `4.16.1`.</p>
<p>## Technical details</p>
<p>Cloudreve creates WOPI viewer sessions in `pkg/filemanager/manager/viewer.go`:</p>
<p>```go
sessionID := uuid.Must(uuid.NewV4()).String()
token := util.RandStringRunesCrypto(128)
sessionCache := &amp;ViewerSessionCache{
    ID:       sessionID,
    Uri:      file.Uri(false).String(),
    UserID:   m.user.ID,
    ViewerID: viewer.ID,
    FileID:   file.ID(),
    Version:  version,
    Token:    fm…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-c3jm-gv5r-9wcp"/>
  </entry>
</feed>
