Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

GHSA-7hm9-v7vf-7g4w kernel

HIGH

GHSA-7hm9-v7vf-7g4w is a high-severity (CVSS 7.7) 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: Path Traversal via unvalidated avID in RenderAttributeView/AV read endpoints : reader-reachable cross-scope attribute-view disclosure

Also known asCVE-2026-69086GO-2026-6373
Published
Sep 3, 2026
Updated
Sep 10, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 19, 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 GHSA-7hm9-v7vf-7g4w.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs29th percentile — riskier than 29% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-7hm9-v7vf-7g4w plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 377,166 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

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/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.

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 GHSA-7hm9-v7vf-7g4w is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-7hm9-v7vf-7g4w can be triaged on real exposure rather than presence alone.

Tailored to GHSA-7hm9-v7vf-7g4w. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

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 GHSA-7hm9-v7vf-7g4w in your dependencies?

O3 Security finds GHSA-7hm9-v7vf-7g4w across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

GHSA-7hm9-v7vf-7g4w: kernel (High 7.7) | O3 Security