NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

CVE-2026-69086 — kernel

CVE-2026-69086 is a Path Traversal vulnerability in github.com/siyuan-note/siyuan/kernel. A fix is available for github.com/siyuan-note/siyuan/kernel — see the affected versions and patch details below.

SiYuan before v3.7.3 Path Traversal via unvalidated avID

Also known asGHSA-7hm9-v7vf-7g4wGO-2026-6373
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 3, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-69086.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs45th percentile — riskier than 45% of all scored CVEsHighest risk
0.00%0.34%0.69%1.03%0.4%0.5%0.5%0.5%Sep 26Nov 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
🐹github.com/siyuan-note/siyuan/kernel

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

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/getAttributeViewKeysByID → arg["avID"]
  • POST /api/av/getAttributeViewKeys  → arg["id"]
  • POST /api/av/getCurrentAttrViewImages → arg["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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/siyuan-note/siyuan/kernelall versions0.0.0-20260720151813-0f5a0e7c67b0go get github.com/siyuan-note/siyuan/kernel@v0.0.0-20260720151813-0f5a0e7c67b0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/siyuan-note/siyuan/kernel, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/siyuan-note/siyuan/kernel to 0.0.0-20260720151813-0f5a0e7c67b0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-69086 is resolved across your whole dependency graph.

  3. Workarounds

    Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.

Frequently Asked Questions

**CVE:** This vulnerability corresponds to [CVE-2026-69086](https://nvd.nist.gov/vuln/detail/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 `RoleRe
O3 Security · Impact-Aware SCA

Is CVE-2026-69086 in your dependencies?

Find it across Go, including transitive dependencies.

CVE-2026-69086: kernel CSRF — Fix Available