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

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.