GHSA-vw86-c94w-v3x4 — kernel
HIGHGHSA-vw86-c94w-v3x4 is a high-severity (CVSS 8.5) CWE-24 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: Publish Reader Path Traversal Delete via `removeUnusedAttributeView`
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-vw86-c94w-v3x4.
EPSS Exploitation Probability
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-vw86-c94w-v3x4 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,636 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
github.com/siyuan-note/siyuan/kernelReal-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
Summary
The endpoint /api/av/removeUnusedAttributeView is vulnerable to a path traversal (CWE-22) that allows an attacker to delete arbitrary .json files on the server.
The issue arises because user-controlled input (id) is directly used in filesystem path construction without validation or restriction.
Access to this endpoint (e.g., via a Reader-role or publish context) is considered a precondition and not part of the vulnerability. The root cause is unsafe path handling.
Steps To Reproduce
- Ensure the target instance has the publish service enabled (or any valid access to the endpoint).
- Send the following request:
POST /api/av/removeUnusedAttributeView HTTP/1.1
Host: <target>
Content-Type: application/json
{
"id": "../../../conf/conf"
}
- Observe that the request is accepted.
- The server resolves the path outside the intended directory and deletes the target file.
Impact
An attacker can delete arbitrary .json files within the workspace directory.
This may lead to:
- Deletion of global configuration files (e.g.,
conf/conf.json) - Loss of user data and application state
- Corruption of workspace metadata
- Persistent application instability or forced recovery
This represents a server-side arbitrary file deletion primitive, which can have severe impact depending on the targeted files.
Technical Details
The vulnerable code constructs file paths as follows:
filepath.Join(util.DataDir, "storage", "av", id+".json")
Because id is not validated, attackers can inject path traversal sequences such as ../ to escape the intended directory.
Example payloads
../local→data/storage/local.json../../storage/outline→data/storage/outline.json../../../conf/conf→conf/conf.json
No validation or restriction is applied to:
- input format
- path normalization
- directory boundaries
Root Cause
- Untrusted user input (
id) is directly used in filesystem path construction - No input validation or sanitization
- No enforcement that the resolved path stays within the intended directory
Remediation
-
Validate input strictly
- Only allow valid Attribute View IDs
- Reject any input containing path traversal sequences
-
Enforce directory boundaries
base := filepath.Join(util.DataDir, "storage", "av")
absPath := filepath.Join(base, id+".json")
if !util.IsSubPath(base, absPath) {
return error
}
-
Normalize paths before use
- Ensure canonical paths cannot escape the base directory
-
Add additional logical checks
- Verify that the target object is valid and allowed to be deleted
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/siyuan-note/siyuan/kernel | all versions | 3.6.40.0.0-20260407035653-2f416e5253f1go get github.com/siyuan-note/siyuan/kernel@v3.6.40.0.0-20260407035653-2f416e5253f1 |
Detection & mitigation playbook
Open-source dependencyDetect
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.
Fix
Update github.com/siyuan-note/siyuan/kernel to 3.6.40.0.0-20260407035653-2f416e5253f1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vw86-c94w-v3x4 is resolved across your whole dependency graph.
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.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-vw86-c94w-v3x4 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-vw86-c94w-v3x4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-vw86-c94w-v3x4 in your dependencies?
O3 Security finds GHSA-vw86-c94w-v3x4 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.