CVE-2026-109310 in SiYuan
Summary
by MITRE • 10/12/2026
SiYuan v3.1.12 before v3.8.6 fails to restrict the Sprig template function map in the /api/icon/getDynamicIcon content parameter, allowing resource exhaustion. A publish reader, or anyone when publish auth is disabled, can use uncapped functions like until to OOM-kill the kernel with one request.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability identified in SiYuan versions prior to 3.8.6 represents a critical server-side template injection flaw rooted in the improper restriction of dynamic function execution within its content processing pipeline. Specifically, the application fails to adequately sanitize or limit the Sprig template functions available during the rendering of the /api/icon/getDynamicIcon endpoint's content parameter. This oversight allows an attacker with publish reader privileges, or any user if authentication is disabled for published documents, to inject malicious templates that leverage uncapped iterative functions such as until. The core technical flaw lies in the lack of input validation and function whitelisting mechanisms when processing these dynamic inputs, effectively granting unauthorized actors control over server-side resource allocation through template logic rather than direct code execution.
From a technical perspective, this vulnerability exploits the powerful capabilities inherent to the Sprig library, which provides numerous helper functions for Go-based applications. By utilizing an uncapped loop function like until, an attacker can construct a request that triggers infinite or excessively long iterations on the server side. This results in rapid and uncontrolled consumption of CPU cycles and memory resources. The operational impact is severe, as this resource exhaustion can lead to Out Of Memory (OOM) conditions within the application process. In many Linux-based deployments, such extreme memory pressure may trigger the kernel's OOM killer, which forcibly terminates processes to free up system memory. This action disrupts service availability for all users and requires manual intervention or automated recovery scripts to restore normal operations, thereby constituting a significant Denial of Service condition.
This vulnerability aligns with CWE-787, which describes out-of-bounds write vulnerabilities that can lead to denial of service through resource exhaustion, although in this specific context, it manifests more directly as CWE-400: Uncontrolled Resource Consumption. The attack vector is classified under the ATT&CK framework technique T1496: Resource Hijacking, where an adversary uses computing resources for their own purposes or causes a disruption by exhausting system resources. Furthermore, because the vulnerability can be triggered via HTTP requests to a specific API endpoint without requiring high-level administrative privileges if publish authentication is disabled, it also touches upon aspects of CWE-284: Improper Access Control and CWE-915: Improper Restriction of Functional Element Usage. The ability for lower-privileged users or anonymous access points to impact the stability of the entire server highlights a critical gap in privilege separation and input sanitization strategies within the application's architecture.
To mitigate this vulnerability, immediate action is required by upgrading SiYuan to version 3.8.6 or later, where these restrictions on Sprig template functions have been implemented. In environments where an upgrade is not immediately feasible, administrators should consider disabling public publishing features if they are not strictly necessary, thereby removing the attack surface for anonymous users. Additionally, implementing a Web Application Firewall with rules capable of detecting and blocking anomalous patterns in HTTP request bodies associated with heavy computational loads or specific template injection signatures can provide a layer of defense-in-depth. It is also advisable to review server-level resource limits using tools like cgroups or systemd service overrides to isolate the impact of such attacks, ensuring that even if an OOM condition occurs, it does not cascade into broader system instability affecting other critical services running on the same host.