CVE-2026-74802: Cross-Site WebSocket Hijacking (CSWSH) in SiYuan Knowledge Workspace

SiYuan is an open-source, local-first knowledge management platform developed in Go. To support real-time data synchronization, RPC functions, and plugin communication, the application exposes several WebSocket endpoints. These endpoints run on port 6806 by default and handle highly privileged system activities.\n\nOne of the most sensitive operations exposed is the administrative network proxy endpoint, located at /ws/network/proxy. This route is designed to tunnel network traffic directly through the SiYuan kernel binary. Because this endpoint and several others lack validation controls, they represent a significant attack surface to malicious actors online.\n\nUnder standard Same-Origin Policy (SOP) rules, web browsers do not restrict cross-site WebSocket handshakes. It is the responsibility of the receiving server to validate the Origin header sent in the initial HTTP upgrade request. When this validation is omitted, any third-party script running in a user's browser can interact with the WebSocket server, bypassing conventional CORS restrictions.

The root cause of CVE-2026-74802 is an Origin Validation Error (CWE-346) in the initialization of the application's WebSocket upgrader instances. Specifically, within kernel/api/network.go, the CheckOrigin callback function of the gorilla/websocket library was explicitly overridden to bypass security checks.\n\nThe original implementation defined a CheckOrigin callback that unconditionally returned true. This explicit instruction forced the Go web server to accept incoming WebSocket connections regardless of the domain specified in the request's Origin header. An attacker-controlled site could thus successfully initiate a handshake.\n\nThis structural security defect extended beyond the proxy endpoint. The primary WebSocket server running inside kernel/server/serve.go used the melody library without configuring any origin checks. Likewise, the broadcast channels in kernel/api/broadcast.go and the plugin-based RPC endpoints in kernel/plugin/rpc.go used Go WebSocket Server (GWS) upgraders that lacked verification controls.

In vulnerable versions of SiYuan, the network proxy endpoint was upgraded using the following structure in kernel/api/network.go:\n\ngo\n// Vulnerable: CheckOrigin returns true unconditionally\nupgrader := websocket.Upgrader{\n\tCheckOrigin: func(r *http.Request) bool { return true },\n}\nclientConn, upgradeErr := upgrader.Upgrade(c.Writer, c.Request, upgradeHeaders)\n\n\nBecause the server does not perform checks, browsers transmitting the upgrade request automatically supply any existing session cookies. The server accepts the handshake and opens a persistent TCP socket. The fixed implementation replaces this anonymous function with an origin-checking utility function:\n\ngo\n// Patched: Origin header is verified against the Host header\nupgrader := websocket.Upgrader{\n\tCheckOrigin: func(r *http.Request) bool {\n\t\treturn util.IsSessionOriginAllowed(r.Header.Get(\"Origin\"), r.Host)\n\t},\n}\nclientConn, upgradeErr := upgrader.Upgrade(c.Writer, c.Request, upgradeHeaders)\n\n\nTo ensure complete system coverage, similar checks were added across all WebSocket routers. For example, in the broadcast handler in kernel/api/broadcast.go:\n\ngo\nwebsocket := melody.New()\n// Upgrader now validates origin headers\nwebsocket.Upgrader.CheckOrigin = func(r *http.Request) bool {\n\treturn util.IsSessionOriginAllowed(r.Header.Get(\"Origin\"), r.Host)\n}\n

To exploit this vulnerability, an attacker must lure an authenticated SiYuan user to visit a malicious website under the attacker's control. The malicious page runs client-side JavaScript that attempts to construct a WebSocket connection back to the victim's local loopback interface.\n\nmermaid\ngraph LR\n AttackerHost[\"Attacker Page (evil.com)\"] -- \"1. Serves exploit JS\" --> VictimBrowser[\"Victim's Browser\"]\n VictimBrowser -- \"2. WS Handshake (Origin: evil.com)\" --> SiYuan[\"SiYuan (localhost:6806)\"]\n SiYuan -- \"3. Returns Connection Accepted (101)\" --> VictimBrowser\n VictimBrowser -- \"4. Sends malicious proxy connect\" --> SiYuan\n SiYuan -- \"5. Exploit connects internal DB\" --> InternalService[\"Internal Network (192.168.1.50)\"]\n\n\nBecause the application is running locally on port 6806, the exploit script targets ws://127.0.0.1:6806/ws/network/proxy. Once the connection is open, the attacker sends control messages specifying target internal hosts. The local SiYuan Go binary acts as a forward proxy, connecting to localized targets and returning raw responses back to the attacker's script.

The CVSS base score of 8.2 reflects the significant threat this flaw poses to host environments. Because the target is typically a local installation on a user's workstation or a container inside a private network segment, successful exploitation facilitates pivoting.\n\nAttackers can leverage the compromised connection to perform port scanning against the local host and adjacent LAN environments. They can also target internal services, such as database administration interfaces or cloud instance metadata services (IMDS), which are normally protected behind perimeter firewalls.\n\nThis attack sequence requires zero authentication from the attacker's perspective, as it leverages the victim's ambient browser authentication. It results in high confidentiality loss and moderate integrity loss, with the compromised host performing unauthorized actions under the identity of the authenticated user.

The primary remediation strategy is upgrading the SiYuan installation to version 3.7.4 or later. In these updated versions, the developers implemented rigorous checking routines via IsSessionOriginAllowed to confirm the request origin matches the allowed deployment host.\n\nFor environments where patching cannot be immediately completed, administrators should apply local network mitigations. Restrict access to port 6806 by binding the application service specifically to 127.0.0.1 rather than 0.0.0.0. Implement local firewall policies (iptables or Windows Firewall) to drop incoming external connections on this port.\n\nTo monitor for potential exploitation attempts, security operations teams should analyze proxy logs for WebSocket upgrade requests where the Origin header contains an external, unknown, or null value. Additionally, inspect local process execution logs to detect unexpected outbound traffic originating from the SiYuan binary.