Summary
SiYuan: Cross-Site WebSocket Hijacking on the admin-only network proxy endpoint (/ws/network/proxy) via explicit CheckOrigin: true bypass
High
Package
gomod github.com/siyuan-note/siyuan/kernel
Affected versions
3.7.3
Patched versions
(none yet, leave blank until a fix is released)
Description
/ws/network/proxy is an admin-only WebSocket forward-proxy endpoint (target URL and headers fully attacker-specifiable via query parameters). Its websocket.Upgrader explicitly overrides CheckOrigin to unconditionally return true, disabling the origin validation that the gorilla/websocket library otherwise enforces by default. WebSocket handshake requests are not subject to CORS preflight at all (unlike fetch/XHR), so origin validation for WebSocket endpoints has to be done deliberately by the server; here it has been deliberately turned off instead. Combined with the endpoint's own query-parameter-driven proxy target, this is a textbook Cross-Site WebSocket Hijacking (CSWSH) primitive on a capability that amounts to an authenticated network pivot through the SiYuan kernel process.
Details
// kernel/api/network.go:501
upgrader := websocket.Upgrader{
CheckOrigin: func(r *http.Request) bool { return true },
}
clientConn, upgradeErr := upgrader.Upgrade(c.Writer, c.Request, upgradeHeaders)
Route registration (admin-role-gated):
// kernel/api/router.go:614
ginServer.Handle("GET", "/ws/network/proxy", model.CheckAuth, model.CheckAdminRole, wsProxy)
The proxy target is fully attacker-controllable via query parameters, decoded and dialed directly:
// kernel/api/network.go:348
func parseForwardProxyParams(c *gin.Context) (parsedURL *url.URL, headers *http.Header, timeout time.Duration, err error) {
uParam := c.Query("u")
...
uBytes, decErr := base64.RawURLEncoding.DecodeString(uParam)
...
parsedURL, err = url.ParseRequestURI(string(uBytes))
...
hParam := c.Query("h") // optional forwarded headers, also base64-encoded
A malicious webpage can construct, entirely from JavaScript with no special access:
new WebSocket("ws://127.0.0.1:6806/ws/network/proxy?u=" + base64url(attackerChosenTargetURL));
WebSocket handshake requests are GET requests carrying ambient cookies exactly like any other cross-site navigation, and are not covered by CORS preflight protections at all, this is a distinct attack surface from ordinary fetch/XHR-based CSRF, and easy to overlook precisely because the usual CORS mental model doesn't apply to it. Whether this is currently exploitable in a given browser depends on the same session-cookie SameSite configuration already covered by a separate report on this repository (no explicit SameSite is set on the session cookie), but even where that provides incidental protection today, the explicit CheckOrigin: func(r *http.Request) bool { return true } override removes a defense-in-depth layer that would otherwise exist automatically from the WebSocket library's own safe default, and is worth fixing independently of the cookie-attribute question.
PoC
No live browser PoC was run for this report, this is a code-level confirmation that the CheckOrigin override exists and unconditionally returns true, combined with tracing the fully attacker-controlled proxy-target construction. I also checked whether the other WebSocket-adjacent endpoints (/ws/plugin/rpc, /ws/broadcast) share this issue: they use a different WebSocket library (gws, not gorilla/websocket) with a different upgrade code path I have not independently verified for its own origin-checking defaults, flagging this as worth a follow-up check by your team rather than claiming it applies there too.
## Affected products
| Field | Value |
|---|---|
| Ecosystem | **Go** |
| Package name | `github.com/siyuan-note/siyuan/kernel` |
| Affected versions | `<= 3.7.3` (confirmed present in 3.7.3; maintainers should confirm lower bound) |
| Patched versions | *(none yet, leave blank until a fix is released)* |
## Severity
| Field | Value |
|---|---|
| Vector string | `CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:N/I:N/A:N` |
| Score | **5.5 (Medium)**, reflecting that real-world exploitability depends on the co-occurring session-cookie `SameSite` question (also separately reported) and requires a victim with an active admin session to visit an attacker-controlled page (`AC:H`, `UI:R`); I'd expect this to be scored higher by your team if you determine the cookie/browser-behavior precondition is reliably met, since the underlying capability (network pivot through the kernel process) is significant. |
## Weaknesses (CWE)
- **CWE-346**, Origin Validation Error (primary, this is the textbook CWE for CSWSH)
- **CWE-352**, Cross-Site Request Forgery (the broader category this specific WebSocket variant falls under)
- **CWE-918**, Server-Side Request Forgery (secondary, the resulting capability once a connection is hijacked)
-
Impact
If reachable (dependent on browser/cookie-attribute behavior at time of exploitation, as above), a malicious website visited by a user with an active, admin-privileged SiYuan session could open a WebSocket connection to this endpoint and direct the SiYuan kernel process to proxy arbitrary network traffic to an attacker-chosen target, effectively an authenticated SSRF/network-pivot primitive, using the victim's own machine and any network position it has (e.g., internal/localhost-only services on the victim's LAN that aren't reachable from the public internet), entirely via a drive-by visit to an unrelated website while SiYuan happens to be running.
A victim's authenticated browser session is used to submit forged requests to an application that cannot distinguish them from legitimate ones. Typical impact: state-changing actions performed as the victim without their consent.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Replace CheckOrigin: func(r *http.Request) bool { return true } with a real check, validate the Origin header against the expected local/loopback origin (or the configured workspace's own address), mirroring how IsLoopbackCallback-style validation is already done correctly elsewhere in this codebase (e.g. the MCP OAuth client's loopback-callback check). Also worth auditing the gws-based WebSocket endpoints (/ws/plugin/rpc, /ws/broadcast) for their own origin-validation defaults, since I did not verify those independently.
Frequently Asked Questions
- What is CVE-2026-74802? CVE-2026-74802 is a low-severity cross-site request forgery (CSRF) vulnerability in github.com/siyuan-note/siyuan/kernel (go), affecting versions < 0.0.0-20260803045322-cb67e0b4fab5. It is fixed in 0.0.0-20260803045322-cb67e0b4fab5. A victim's authenticated browser session is used to submit forged requests to an application that cannot distinguish them from legitimate ones.
- Which versions of github.com/siyuan-note/siyuan/kernel are affected by CVE-2026-74802? github.com/siyuan-note/siyuan/kernel (go) versions < 0.0.0-20260803045322-cb67e0b4fab5 is affected.
- Is there a fix for CVE-2026-74802? Yes. CVE-2026-74802 is fixed in 0.0.0-20260803045322-cb67e0b4fab5. Upgrade to this version or later.
- Is CVE-2026-74802 exploitable, and should I be worried? Whether CVE-2026-74802 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-74802 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-74802? Upgrade
github.com/siyuan-note/siyuan/kernelto 0.0.0-20260803045322-cb67e0b4fab5 or later.