Skip to content

SiYuan: Path Traversal via unvalidated avID in RenderAttributeView/AV read endpoints : reader-reachable cross-scope attribute-view disclosure

High severity GitHub Reviewed Published Jul 20, 2026 in siyuan-note/siyuan • Updated Sep 3, 2026

Package

gomod github.com/siyuan-note/siyuan/kernel (Go)

Affected versions

< 0.0.0-20260720151813-0f5a0e7c67b0

Patched versions

0.0.0-20260720151813-0f5a0e7c67b0

Description

CVE: This vulnerability corresponds to CVE-2026-69086.

Summary

Four attribute-view read endpoints build a filesystem path from a caller-controlled id/avID and read it without confining the result to the attribute-view storage directory (DataDir/storage/av/). On the load (file-exists) code path there is no boundary check, so an avID containing ../ segments escapes storage/av/ and causes the kernel to read a .json file elsewhere in the workspace.

The endpoints require only CheckAuth, which the publish service's RoleReader token satisfies; when Publish.Auth.Enable is false the publish proxy uses the anonymous account, making the surface reachable with no credentials.

Details

Affected endpoints (all gated by CheckAuth only, no CheckAdminRole):

  • POST /api/av/renderAttributeView  → arg["id"]
  • POST /api/av/getAttributeViewKeysByIDarg["avID"]
  • POST /api/av/getAttributeViewKeys  → arg["id"]
  • POST /api/av/getCurrentAttrViewImagesarg["id"]

In model.RenderAttributeView (model/attribute_view_render.go), the only identifier guard ast.IsNodeIDPattern(avID) sits inside the if !filelock.IsExist(existPath) (create) branch:

existPath = GetAttributeViewDataPath(avID)      // path built from avID, no check
if !filelock.IsExist(existPath) {               // NOT-EXIST / CREATE branch
    if !createIfNotExist {
        return // NotFound
    }
    if !ast.IsNodeIDPattern(avID) {             // <-- ONLY id guard, create branch only
        return ErrInvalidID
    }
    // ... create ...
}
attrView, err = av.ParseAttributeView(avID)     // LOAD runs unconditionally

When the traversal avID resolves to a file that already exists, the !filelock.IsExist(...) condition is false, the entire block (including the line with ast.IsNodeIDPattern) is skipped, and control falls straight through to av.ParseAttributeView(avID). That function rebuilds the path via filepath.Join(DataDir, "storage", "av", avID+".json") and calls filelock.ReadFile with no filepath.Rel / IsSubPath / .. rejection:

// av.ParseAttributeView -> attributeViewDataPathByBox / GetAttributeViewDataPath
avJSONPath = filepath.Join(DataDir, "storage", "av", avID+".json")  // no boundary check
// -> parseAttributeViewByPathInBox(avJSONPath, boxID)
data, _ = filelock.ReadFile(avJSONPath)                             // SINK

filepath.Join cleans the path but does not reject .. segments, so it provides no containment. The three getAttributeView* endpoints call ParseAttributeView with no create branch at all, so they never even reach the ast.IsNodeIDPattern check same defect, same auth tier.

The root cause is that identifier validation is placed on a single code branch rather than confining the load to the AV base directory, so the load path reads a caller-controlled location.

PoC

Precondition: publish mode enabled (default port 6808); reachable by a RoleReader publish token, or anonymously when Publish.Auth.Enable is false.

A request to /api/av/renderAttributeView with an id composed of ../ path segments that resolves to an existing .json file outside DataDir/storage/av/ causes that file to be read and parsed instead of being rejected, because the identifier validation is only reached on the not-exist/create branch.

I have withheld the exact encoded id value from this draft to avoid publishing a live traversal against internet-exposed publish instances. I'm happy to provide the precise value and a screenshot privately in this thread on request.

Impact

An authenticated publish RoleReader or an anonymous client when publish auth is disabled can cause the kernel to read .json files outside the attribute-view directory. Because the loaded file is unmarshalled into the attribute-view structure, the reliable primitives are:

  1. Disclosure of attribute-view (database) content from other scopes/notebooks the reader is not authorized to see.
  2. A .json-path existence oracle for arbitrary workspace locations.

Files not conforming to the AV schema are read but reflect little content, and the .json suffix is force-appended, so this is not a general arbitrary-file read. No admin role, CSRF token, or write permission is required.

Suggested fix

Validate avID with ast.IsNodeIDPattern before path construction on all branches (move it ahead of FindAttributeViewPath / GetAttributeViewDataPath), or preferably, so every caller inherits it confine at the sink: in attributeViewDataPathByBox / GetAttributeViewDataPath, compute the joined path and reject it unless filepath.Rel(avBaseDir, cleaned) stays within avBaseDir (no leading ..). Sink-side confinement also covers the three getAttributeView* endpoints that never reach the create-branch guard.

References

@88250 88250 published to siyuan-note/siyuan Jul 20, 2026
Published to the GitHub Advisory Database Sep 3, 2026
Reviewed Sep 3, 2026
Last updated Sep 3, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
None
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(28th percentile)

Weaknesses

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. Learn more on MITRE.

CVE ID

CVE-2026-69086

GHSA ID

GHSA-7hm9-v7vf-7g4w

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.