---
id: "CVE-2026-62204"
kind: "vulnerability"
aliases: ["CVE-2026-62204", "GHSA-rpx2-p6hp-x5gj"]
title: "SiYuan: Missing consistency check between packageName and repoURL/repoHash in bazaar package install allows overwriting an existing, trusted plugin"
severity: "medium"
cvss: 6.6
epss: 0.0009399999980814755
exploited: false
status: "open"
category: "other"
products: [{"name": "github.com/siyuan-note/siyuan/kernel", "fixed": ["0.0.0-20260808010544-26ccb40d390e"], "affected": "< 0.0.0-20260808010544-26ccb40d390e", "ecosystem": "go"}]
ecosystems: ["go"]
tags: ["cwe-345", "cwe-668", "desktop", "electron", "other", "self-hosted", "siyuan"]
not_affected_if: ["default-config"]
published_at: "2026-08-22T13:16:39+00:00"
first_seen_at: "2026-10-23T19:11:31+00:00"
updated_at: "2026-10-23T23:44:52+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-rpx2-p6hp-x5gj", "first_seen_at": "2026-10-23T19:11:31+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62204", "first_seen_at": "2026-10-23T23:44:52+00:00"}]
---

# SiYuan: Missing consistency check between packageName and repoURL/repoHash in bazaar package install allows overwriting an existing, trusted plugin

SiYuan's bazaar install endpoints take the package name, download URL and hash as independent fields, so a request can overwrite an already-installed plugin, widget, icon, template or theme directory with different content. An attacker who already has same-origin script execution in the SiYuan renderer can use this to replace a trusted plugin's files so the replacement runs on the next app restart.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- go:github.com/siyuan-note/siyuan/kernel affected < 0.0.0-20260808010544-26ccb40d390e fixed 0.0.0-20260808010544-26ccb40d390e

## Fix

Upgrade to a SiYuan build at or after commit 26ccb40d390e (0.0.0-20260808010544-26ccb40d390e) per the advisory's fixed version.

## Timeline

- 2026-10-23T19:11:31+00:00 ghsa https://github.com/advisories/GHSA-rpx2-p6hp-x5gj
- 2026-10-23T23:44:52+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-62204

## From the sources

## Summary

`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`:
```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`:
```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`:
```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:
```go
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:
```go
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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_