CVE-2026-72809: Authentication Bypass in SiYuan via Localhost Trust Spoofing

SiYuan is a local-first personal knowledge management system that executes on a Go-based backend kernel and interacts with clients through an API engine. This architecture integrates a built-in HTTP server to process requests from local desktop applications, mobile clients, and web browsers. To facilitate communication with helper applications and browser extensions without requiring complex token configurations, the application deploys a local reverse proxy listening on a fixed network port.

The core of the vulnerability resides in the CheckAuth middleware handler within the kernel's session module. The handler implements an implicit security-critical decision based on the origin IP address of incoming HTTP connections. Specifically, any request arriving from a loopback address is designated as originating from a trusted local administrator, bypassing user-configured authentication gates.

This trust model fails to account for intermediate proxy layers. The default reverse proxy implementation (listening on port 6806) forwards external incoming connections to the backend kernel over the local loopback interface. Because the proxy does not attach or translate forwarding headers, the backend kernel perceives the connection source socket as localhost, granting administrative privileges to remote unauthenticated attackers.

In SiYuan versions up to and including v3.7.2, the authentication middleware in kernel/model/session.go evaluates incoming client sessions using a loopback IP validation function. The application inspects the raw HTTP request structure's socket source address to identify trusted connections. When the evaluation of util.IsLocalHost(c.Request.RemoteAddr) resolves to true, the validation engine exempts the client from standard access verification tests.

The application exposes a static reverse proxy on port 6806, defined in kernel/server/proxy/fixedport.go, to receive commands from integration extensions. In the vulnerable implementation, this proxy is constructed using Go's standard httputil.NewSingleHostReverseProxy without any explicit configuration for upstream proxy headers. When a remote client issues a request to port 6806, the proxy establishes a new TCP connection to the backend API server. Because both components reside on the same host, the source address of this internal connection resolves to the loopback interface.

The backend Gin web engine was not configured with trusted proxy boundaries. Under default conditions, Gin does not parse upstream routing chains or evaluate client headers when resolving source addresses. Consequently, the request payload is evaluated by CheckAuth as originating from 127.0.0.1, bypassing the AccessAuthCode requirement. This logic mismatch permits an external user to spoof localhost status and claim administrative privileges.

An inspection of the vulnerable codebase in kernel/model/session.go shows how the CheckAuth function performs origin-based validation. The middleware assesses the direct network socket of the incoming request directly before validating credentials:

// Vulnerable CheckAuth implementation
func CheckAuth(c *gin.Context) bool {
    // Direct check on the socket RemoteAddr
    localhost := util.IsLocalHost(c.Request.RemoteAddr)
    if localhost {
        // Bypasses the AccessAuthCode check entirely
        c.Set("role", RoleAdministrator)
        return true
    }
    
    // Standard authentication logic continues below
    ...
}

The corresponding reverse proxy setup in kernel/server/proxy/fixedport.go lacked the logic required to append the actual external client's source IP address:

// Vulnerable proxy construction
proxy := httputil.NewSingleHostReverseProxy(util.ServerURL)
proxy.Transport = &http.Transport{
    TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
}

The fix implemented in commit 9c16e9851f0b5d7ed179e5c2fca15a7724666871 introduces a dual-verification mechanism. The server now restricts trusted proxies within Gin, enabling the framework to process forwarding headers securely. A new helper function, IsLocalRequest, is integrated into the session validation routine to ensure both the socket origin and the forwarded client IP originate from the loopback scope:

// Patched session validation helper
func IsLocalRequest(c *gin.Context) bool {
    // Both the physical connection and resolved client IP must map to loopback
    return util.IsLocalHost(c.Request.RemoteAddr) && util.IsLocalHostname(c.ClientIP())
}

Additionally, the reverse proxy in fixedport.go was refactored to populate standard HTTP forwarding headers. The rewrite callback now executes request.SetXForwarded(), forcing the injection of the external caller's IP into the header chain:

// Patched proxy construction with proper rewrite rule
func newFixedPortReverseProxy(target *url.URL) *httputil.ReverseProxy {
    return &httputil.ReverseProxy{
        Rewrite: func(request *httputil.ProxyRequest) {
            request.SetURL(target)
            request.Out.Host = request.In.Host
            request.SetXForwarded() // Generates X-Forwarded-For header
        },
        Transport: &http.Transport{
            TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
        },
    }
} 

Exploitation of this vulnerability requires network access to the port bound by the SiYuan fixed-port proxy. If the service is configured to bind to a wildcard address (0.0.0.0) or is accessible over a local network segment, a remote unauthenticated attacker can execute administrative API calls directly.

An attacker crafts a standard HTTP request targeting one of the internal administrative endpoints, such as /api/system/getWorkspaceInfo or /api/system/getNetwork. The request is dispatched directly to port 6806 of the target machine. When the reverse proxy intercepts this request, it routes it to the API kernel. Because the forwarding step is conducted over a loopback socket, the kernel processes the request as originating from 127.0.0.1, satisfying the bypass criteria.

The response returns administrative data back to the attacker. No credential submission or interaction with the lockscreen interface is required.

An unauthenticated remote attacker can exploit this authentication bypass to gain full administrative privileges over the affected SiYuan endpoints. This access exposes critical functions including system shutdown (/api/system/exit), network diagnostic data (/api/system/getNetwork), and workspace metadata (/api/system/getWorkspaceInfo). Additionally, attackers can read and retrieve arbitrary files stored within the local application workspace via /assets/* and /export/* routes.

The vulnerability is classified under CVSS v3.1 with a base score of 8.0 (High), reflecting low attack complexity and no requirement for prior privileges or user interaction. If the application environment runs with elevated local system privileges, the exposure of these file-system and system management APIs poses a substantial threat to system integrity and data confidentiality.

There is currently no evidence of active exploitation of this vulnerability in the wild, and it is not documented within the CISA Known Exploited Vulnerabilities catalog. The exploit maturity is classified as conceptual, established primarily through static code analysis and local validation.

To resolve this vulnerability, administrators and users must upgrade the SiYuan installation to version 3.7.4 or newer. The update implements the corrected validation checking routine, preventing source IP spoofing over the local reverse proxy interface.

If immediate patching is not possible, the risk can be mitigated by modifying the binding interface configuration of the application. Ensure the fixed-port proxy is configured to listen strictly on the local loopback interface (127.0.0.1) rather than a wildcard interface (0.0.0.0). This restricts access exclusively to local processes and prevents external network hosts from routing traffic through the proxy.

Additionally, network administrators should deploy firewall rules to block incoming TCP traffic on port 6806 from untrusted external networks. Monitor application access logs for unexpected requests querying administrative endpoints like /api/system/ from remote IP addresses.