CVE-2026-74905 in SiYuan
Summary
by MITRE • 08/18/2026
SiYuan before v3.7.4 contains a server-side request forgery (SSRF) vulnerability in the isPrivateIP function in kernel/util/net.go, used by SSRFSafeDialer to enforce SSRF protection in SafeMode. The function only checks for loopback, link-local unicast, private, and unspecified addresses and does not recognize IPv6 transition addresses (NAT64 64:ff9b::/96, 6to4 2002::/16, Teredo 2001::/32) that embed private IPv4 destinations. When SafeMode is enabled, an authenticated attacker can bypass the SSRF guard via the network forward proxy, WebSocket proxy, or SSE proxy endpoints by supplying a URL whose hostname resolves to such a transition address, reaching internal services and cloud metadata endpoints (e.g., 169.254.169.254). Because the forward proxy returns the full response body, this is a full-read SSRF that can be used to steal instance credentials, reach internal services, and port-scan internal infrastructure.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in SiYuan versions prior to 3.7.4 represents a critical server-side request forgery flaw rooted in the insufficient validation logic of the isPrivateIP function located within the kernel/util/net.go module. This function serves as the foundational security control for SSRFSafeDialer, which is responsible for enforcing access restrictions when SafeMode is enabled. The core technical deficiency lies in the fact that the implementation only checks against standard IPv4 loopback addresses, link-local unicast ranges, private address spaces defined by RFC 1918, and unspecified zero addresses. It fails to account for IPv6 transition mechanisms such as NAT64 prefixes like 64:ff9b::/96, 6to4 encapsulation via 2002::/16, and Teredo tunneling through 2001::/32. These specific address ranges are designed to facilitate communication between IPv6-only networks and legacy IPv4 infrastructure by embedding private or public IPv4 addresses within the IPv6 structure. By neglecting these transition addresses, the application allows an attacker to bypass SSRF protections simply by resolving a hostname to one of these IPv6 prefixes that maps to an internal destination.
From an operational perspective, this oversight creates a significant security gap for environments where SafeMode is active. An authenticated attacker can exploit this flaw through multiple attack vectors including network forward proxy endpoints, WebSocket proxies, and Server-Sent Events (SSE) proxies. By supplying a URL whose hostname resolves to one of the aforementioned IPv6 transition addresses that point toward internal services or cloud metadata endpoints such as 169.254.169.254, the attacker can successfully route requests through the application server to otherwise restricted resources. Because the forward proxy component returns the full response body rather than just a status code or error message, this constitutes a full-read SSRF vulnerability. This capability transforms what might have been a simple connectivity test into a potent data exfiltration vector, allowing the attacker to retrieve sensitive information from internal services that are not directly exposed to the public internet.
The impact of this vulnerability is severe, particularly in cloud-native or containerized deployments where instance metadata endpoints are commonly targeted for credential theft. An adversary can leverage this SSRF flaw to access 169.254.169.254 and similar metadata services, potentially stealing IAM credentials, API keys, and other sensitive configuration data that grants further control over the cloud infrastructure. Beyond immediate credential theft, the ability to reach internal services enables lateral movement within the network topology. The attacker can perform port scanning against internal hosts to identify running services, vulnerabilities, or misconfigurations, thereby expanding their foothold in the environment. This aligns with ATT&CK technique T1598.002, which describes Spoofing Internal IP Addresses via IPv6 transition mechanisms, and CWE-918, which classifies Server-Side Request Forgery flaws where server-side code makes requests to user-supplied URLs without proper validation of the destination address space.
To mitigate this vulnerability, it is imperative that developers update SiYuan to version 3.7.4 or later, where the isPrivateIP function has been corrected to properly recognize and block IPv6 transition addresses that embed private IP destinations. In addition to upgrading, organizations should implement defense-in-depth strategies by ensuring that SSRF protections are not solely reliant on client-side or application-layer validation but are reinforced at the network perimeter using firewall rules or reverse proxy configurations that restrict outbound connections from the SiYuan service account to only whitelisted external domains and necessary internal subnets. Furthermore, enabling strict egress filtering for cloud metadata endpoints like 169.254.169.254 via host-level firewalls can provide an additional layer of protection against credential theft even if application-layer controls are bypassed. Regular security audits focusing on network validation logic and adherence to CWE-918 guidelines should be conducted to prevent similar oversights in future development cycles.