GHSA-vw86-c94w-v3x4
HIGHGHSA-vw86-c94w-v3x4 is a high-severity (CVSS 8.5) CWE-24 vulnerability in github.com/siyuan-note/siyuan/kernel. O3 Security confirms whether GHSA-vw86-c94w-v3x4 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
SiYuan: Publish Reader Path Traversal Delete via `removeUnusedAttributeView`
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-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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 pinpoints whether GHSA-vw86-c94w-v3x4 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
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 detects GHSA-vw86-c94w-v3x4 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.