CVE-2026-74799 in SiYuan
Summary
by MITRE • 08/17/2026
SiYuan before 3.7.4 registers Go net/http/pprof debug endpoints including heap and goroutine dumps without authentication when --mode flag is not set to exactly prod. Attackers can access /debug/pprof/heap and related endpoints to extract in-memory secrets including AccessAuthCode and AI provider API keys.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified in SiYuan versions prior to 3.7.4 represents a critical misconfiguration of the application's debug infrastructure, specifically involving the Go net/http/pprof package. This standard library component is designed for profiling Go applications during development and troubleshooting, providing endpoints that expose detailed runtime metrics such as heap dumps, goroutine states, and execution traces. In this instance, these sensitive diagnostic interfaces were registered and exposed to network traffic without any form of authentication or access control mechanisms when the application was not explicitly configured with the --mode flag set to prod. This oversight effectively transforms a development-only feature into an unauthenticated attack surface in production-like environments where the mode is left at its default state or set to other non-production values, allowing external actors to interact directly with internal system diagnostics.
The technical flaw lies in the conditional logic governing endpoint registration and access control. By failing to restrict pprof endpoints exclusively to local loopback interfaces or requiring authentication when running in modes that are not strictly production, the application inadvertently leaks critical runtime data. Attackers can exploit this by sending HTTP requests to paths such as /debug/pprof/heap and other related diagnostic routes. The heap dump endpoint is particularly dangerous because it serializes a snapshot of all objects currently allocated on the heap into memory. This snapshot contains references to live variables, including those holding sensitive credentials stored in application memory for active sessions or configured integrations.
The operational impact of this vulnerability is severe due to the nature of the data exposed through these endpoints. Accessing the heap dump allows an attacker to extract plaintext secrets that are currently loaded into the application's memory space. This includes high-value targets such as the AccessAuthCode, which likely serves as a primary authentication token for user sessions or administrative access, and API keys for integrated AI providers. The compromise of these credentials can lead to full account takeover, unauthorized access to private notes and data stored within SiYuan, and potential abuse of third-party services via stolen API keys. This scenario aligns with the Common Weakness Enumeration category CWE-209, which describes an information exposure through an error message or diagnostic output that reveals sensitive system details, as well as CWE-538 regarding insertion of sensitive information into an object for storage or transmission without proper protection.
From a threat intelligence perspective, this vulnerability facilitates initial access and credential harvesting techniques documented in the MITRE ATT&CK framework. The exploitation of debug endpoints to gather intelligence on running processes and memory contents corresponds to T1608, specifically the Steal Application Access Token sub-technique. Furthermore, accessing heap dumps can be categorized under T1005, Data from Local System Retrieval, as it involves extracting data directly from the application's process space without needing to compromise persistent storage files like databases or configuration files on disk. This method of extraction is often more reliable than file-based theft because modern applications frequently encrypt credentials at rest but leave them in plaintext within memory for operational use.
Mitigation strategies must focus on strict separation of development and production environments. The primary remediation involves ensuring that the --mode flag is strictly set to prod in all deployment scenarios, which should inherently disable or restrict access to debug endpoints according to best practices for Go web applications. Additionally, developers should implement explicit middleware checks that verify the request source IP address, restricting pprof endpoints to localhost (127.0.0.1) only, even if they remain registered on other interfaces. For existing deployments, immediate patching to version 3.7.4 or later is required to resolve this configuration flaw. Security teams should also audit their deployment pipelines to ensure that environment variables and command-line flags are correctly propagated during containerization or server startup processes to prevent accidental exposure of diagnostic tools in production contexts.