GHSA-RPX2-P6HP-X5GJ
Vulnerability from github – Published: 2026-10-23 18:38 – Updated: 2026-10-23 18:38Summary
installBazaarPlugin (and the equivalent endpoints for widgets/icons/templates/themes) accept
packageName, repoURL, and repoHash as independent request fields with no validation that
they refer to the same package. packageName alone determines the install destination;
repoURL/repoHash alone determine what content gets downloaded and written there. A request
can name an already-installed, already-enabled plugin as packageName while pointing repoURL/
repoHash at different, attacker-influenced content, silently overwriting the existing plugin's
files.
Affected code
kernel/api/bazaar.go:
util.BindJsonArg("packageName", &packageName, true, true)
util.BindJsonArg("repoURL", &repoURL, true, true)
util.BindJsonArg("repoHash", &repoHash, true, true)
err := model.InstallBazaarPackage("plugins", repoURL, repoHash, packageName, 0)
kernel/model/bazaar.go:
func getPackageInstallPath(pkgType, packageName string) (string, string, error) {
case "plugins":
return filepath.Join(util.DataDir, "plugins", packageName), "plugin.json", nil
kernel/bazaar/install.go:
func installPackage(data []byte, installPath string) (err error) {
...
if err = filelock.Copy(srcPath, installPath); err != nil { return }
return
}
installPath is derived solely from packageName; the downloaded data is derived solely from
repoURL/repoHash; nothing cross-validates them, and installPackage performs no check for
whether installPath already contains an existing package before copying into it. The same
pattern applies to the widget/icon/template/theme install endpoints, which share
getPackageInstallPath.
This does not involve path traversal — installPath always resolves inside
DataDir/plugins/ (or the corresponding directory for other package types), so this is not an
instance of "arbitrary file write outside the workspace path" (excluded by this project's
SECURITY.md). The issue is that the write lands in the wrong, existing location within the
intended directory, not outside it — an authorization/identity-verification gap, not a path
traversal.
Reachability / why this is not trivially remote
The bazaar endpoints are gated by model.CheckAuth, model.CheckAdminRole, model.CheckReadonly.
When no lock-screen password is configured (the common desktop default), CheckAuth still
enforces a same-origin check:
if !localhost || ... || ("" != origin && !util.IsLocalOrigin(origin)) || ... {
// reject with 401
}
I verified IsLocalOrigin/IsLocalHostname correctly parse the Origin header via url.Parse
and check exact hostname / loopback IP:
func IsLocalOrigin(origin string) bool {
if u, err := url.Parse(origin); err == nil {
return IsLocalHostname(u.Hostname())
}
return false
}
func IsLocalHostname(hostname string) bool {
if "localhost" == hostname || strings.HasSuffix(hostname, ".localhost") {
return true
}
if ip := net.ParseIP(hostname); nil != ip {
return ip.IsLoopback()
}
return false
}
This was tested against common bypass patterns (subdomain-suffix tricks like
localhost.attacker.com, and Origin: null as sent by sandboxed iframes) and found no bypass —
this is a correctly-implemented check. This means a purely remote attacker (e.g. a malicious
website) cannot invoke this endpoint via CSRF; a request must originate from SiYuan's own
renderer origin.
Realistic impact
Given SiYuan runs as an Electron app with nodeIntegration: true (per prior advisories in this
repository), a same-origin script-execution primitive (e.g. an XSS bug in the renderer, of which
several have been fixed in this repository recently) is typically already sufficient for direct
code execution. This bug's marginal value is persistence: a transient XSS-driven compromise
can use this endpoint to overwrite an existing, trusted, already-enabled plugin's index.js,
converting a one-time compromise into code that runs on every future launch of the application,
surviving after the original XSS vector is closed.
The overwrite does not effect immediately, via this specific
endpoint. PushReloadPlugin (the websocket event that triggers frontend hot-reload without
restart) is only called from the batch-update path (InstallBazaarPackages, used by
batchUpdatePackage), which explicitly checks if petal != nil && petal.Enabled before forcing
a reload via SetPetalEnabled. The single-package install endpoint (installBazaarPlugin) does
not call PushReloadPlugin at all — it only pushes a generic success toast. So an overwrite via
this endpoint activates on the next app restart or manual plugin toggle, rather than instantly
still a realistic and frequent event for a desktop application, but not an instant hot-reload.
Suggested fix
Verify that packageName matches the package name declared in the downloaded package's own
plugin.json/theme.json/etc. before copying into installPath, and/or refuse to install over
an existing, non-empty destination directory unless the request is explicitly an update of that
same package (matching by source repo identity, not just by request-supplied name).
Verification notes
Confirmed via static source review of kernel/api/bazaar.go, kernel/model/bazaar.go,
kernel/bazaar/install.go, kernel/model/session.go (CheckAuth), kernel/util/net.go
(IsLocalOrigin/IsLocalHostname), and kernel/model/push_reload.go /
app/src/plugin/loader.ts (reload trigger wiring). I do not have a running SiYuan instance
in this environment to execute an end-to-end proof of concept; findings are based on tracing
the actual, unmodified control flow across these files rather than assumption.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260808010544-26ccb40d390e"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-62204"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-668"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-23T18:38:25Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\n`installBazaarPlugin` (and the equivalent endpoints for widgets/icons/templates/themes) accept\n`packageName`, `repoURL`, and `repoHash` as independent request fields with no validation that\nthey refer to the same package. `packageName` alone determines the install destination;\n`repoURL`/`repoHash` alone determine what content gets downloaded and written there. A request\ncan name an already-installed, already-enabled plugin as `packageName` while pointing `repoURL`/\n`repoHash` at different, attacker-influenced content, silently overwriting the existing plugin\u0027s\nfiles.\n\n## Affected code\n\n`kernel/api/bazaar.go`:\n```go\nutil.BindJsonArg(\"packageName\", \u0026packageName, true, true)\nutil.BindJsonArg(\"repoURL\", \u0026repoURL, true, true)\nutil.BindJsonArg(\"repoHash\", \u0026repoHash, true, true)\nerr := model.InstallBazaarPackage(\"plugins\", repoURL, repoHash, packageName, 0)\n```\n\n`kernel/model/bazaar.go`:\n```go\nfunc getPackageInstallPath(pkgType, packageName string) (string, string, error) {\n case \"plugins\":\n return filepath.Join(util.DataDir, \"plugins\", packageName), \"plugin.json\", nil\n```\n\n`kernel/bazaar/install.go`:\n```go\nfunc installPackage(data []byte, installPath string) (err error) {\n ...\n if err = filelock.Copy(srcPath, installPath); err != nil { return }\n return\n}\n```\n\n`installPath` is derived solely from `packageName`; the downloaded `data` is derived solely from\n`repoURL`/`repoHash`; nothing cross-validates them, and `installPackage` performs no check for\nwhether `installPath` already contains an existing package before copying into it. The same\npattern applies to the widget/icon/template/theme install endpoints, which share\n`getPackageInstallPath`.\n\nThis does not involve path traversal \u2014 `installPath` always resolves inside\n`DataDir/plugins/` (or the corresponding directory for other package types), so this is not an\ninstance of \"arbitrary file write outside the workspace path\" (excluded by this project\u0027s\nSECURITY.md). The issue is that the write lands in the *wrong, existing* location within the\nintended directory, not outside it \u2014 an authorization/identity-verification gap, not a path\ntraversal.\n\n## Reachability / why this is not trivially remote\n\nThe bazaar endpoints are gated by `model.CheckAuth`, `model.CheckAdminRole`, `model.CheckReadonly`.\nWhen no lock-screen password is configured (the common desktop default), `CheckAuth` still\nenforces a same-origin check:\n```go\nif !localhost || ... || (\"\" != origin \u0026\u0026 !util.IsLocalOrigin(origin)) || ... {\n // reject with 401\n}\n```\nI verified `IsLocalOrigin`/`IsLocalHostname` correctly parse the `Origin` header via `url.Parse`\nand check exact hostname / loopback IP:\n```go\nfunc IsLocalOrigin(origin string) bool {\n if u, err := url.Parse(origin); err == nil {\n return IsLocalHostname(u.Hostname())\n }\n return false\n}\nfunc IsLocalHostname(hostname string) bool {\n if \"localhost\" == hostname || strings.HasSuffix(hostname, \".localhost\") {\n return true\n }\n if ip := net.ParseIP(hostname); nil != ip {\n return ip.IsLoopback()\n }\n return false\n}\n```\nThis was tested against common bypass patterns (subdomain-suffix tricks like\n`localhost.attacker.com`, and `Origin: null` as sent by sandboxed iframes) and found no bypass \u2014\nthis is a correctly-implemented check. This means a purely remote attacker (e.g. a malicious\nwebsite) cannot invoke this endpoint via CSRF; a request must originate from SiYuan\u0027s own\nrenderer origin.\n\n## Realistic impact\n\nGiven SiYuan runs as an Electron app with `nodeIntegration: true` (per prior advisories in this\nrepository), a same-origin script-execution primitive (e.g. an XSS bug in the renderer, of which\nseveral have been fixed in this repository recently) is typically already sufficient for direct\ncode execution. This bug\u0027s marginal value is **persistence**: a transient XSS-driven compromise\ncan use this endpoint to overwrite an existing, trusted, already-enabled plugin\u0027s `index.js`,\nconverting a one-time compromise into code that runs on every future launch of the application,\nsurviving after the original XSS vector is closed.\n\nThe overwrite does not effect immediately, via this specific\nendpoint. `PushReloadPlugin` (the websocket event that triggers frontend hot-reload without\nrestart) is only called from the batch-update path (`InstallBazaarPackages`, used by\n`batchUpdatePackage`), which explicitly checks `if petal != nil \u0026\u0026 petal.Enabled` before forcing\na reload via `SetPetalEnabled`. The single-package install endpoint (`installBazaarPlugin`) does\nnot call `PushReloadPlugin` at all \u2014 it only pushes a generic success toast. So an overwrite via\nthis endpoint activates on the next app restart or manual plugin toggle, rather than instantly \nstill a realistic and frequent event for a desktop application, but not an instant hot-reload.\n\n## Suggested fix\n\nVerify that `packageName` matches the package name declared in the downloaded package\u0027s own\n`plugin.json`/`theme.json`/etc. before copying into `installPath`, and/or refuse to install over\nan existing, non-empty destination directory unless the request is explicitly an update of that\nsame package (matching by source repo identity, not just by request-supplied name).\n\n## Verification notes\n\nConfirmed via static source review of `kernel/api/bazaar.go`, `kernel/model/bazaar.go`,\n`kernel/bazaar/install.go`, `kernel/model/session.go` (CheckAuth), `kernel/util/net.go`\n(IsLocalOrigin/IsLocalHostname), and `kernel/model/push_reload.go` /\n`app/src/plugin/loader.ts` (reload trigger wiring). I do not have a running SiYuan instance\nin this environment to execute an end-to-end proof of concept; findings are based on tracing\nthe actual, unmodified control flow across these files rather than assumption.",
"id": "GHSA-rpx2-p6hp-x5gj",
"modified": "2026-10-23T18:38:25Z",
"published": "2026-10-23T18:38:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-rpx2-p6hp-x5gj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62204"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/commit/26ccb40d390eb7d9b04673629a58ab1d69cc7e53"
},
{
"type": "PACKAGE",
"url": "https://github.com/siyuan-note/siyuan"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/releases/tag/v3.8.0"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/siyuan-before-plugin-overwrite-via-bazaar-install"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:L/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "SiYuan: Missing consistency check between packageName and repoURL/repoHash in bazaar package install allows overwriting an existing, trusted plugin"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.