CVE-2026-104458 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains a server-side request forgery vulnerability in validateKeyIdUrl() that allows unauthenticated attackers to bypass the SSRF guard using 6to4, NAT64, or IPv4-compatible IPv6 addresses. Attackers can send a crafted Signature keyId to the public actor inbox route to reach cloud metadata, loopback services, or internal hosts.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in YesWiki versions prior to 4.6.7 represents a critical server-side request forgery flaw rooted in insufficient input validation within the validateKeyIdUrl function. This specific weakness allows unauthenticated attackers to circumvent existing security controls designed to prevent outbound requests from reaching internal or restricted network resources. The core of the issue lies in how the application processes IPv6 address formats, specifically failing to adequately sanitize or block addresses that utilize legacy compatibility mechanisms such as 6to4 tunnels, NAT64 prefixes, and IPv4-compatible IPv6 addresses. These specific encoding methods allow an attacker to represent a private IP address, such as one belonging to localhost or internal cloud infrastructure, using an external-looking IPv6 format that the server's validation logic incorrectly perceives as safe for outbound communication.
From a technical perspective, the flaw exploits the ambiguity in how network stacks and application-level firewalls interpret different IPv6 addressing schemes. By crafting a Signature keyId parameter containing one of these specialized IPv6 formats, an attacker can trick the YesWiki instance into initiating HTTP requests to destinations that should be blocked by standard SSRF mitigations. This bypass is particularly dangerous because it targets the public actor inbox route, which may be exposed or accessible through normal application workflows without requiring authentication. The ability to reach cloud metadata services, such as those found in AWS EC2 or Google Cloud Platform, poses a severe risk of credential theft and further system compromise. Additionally, access to loopback services allows attackers to interact with local database ports, administrative interfaces, or other backend microservices that are not intended for external exposure.
The operational impact of this vulnerability is significant, as it effectively neutralizes the primary defense mechanism against SSRF attacks in YesWiki environments. An attacker who successfully exploits this flaw can enumerate internal network services, extract sensitive configuration data from cloud metadata endpoints, and potentially pivot to other systems within the private network. This capability undermines the principle of least privilege by granting external actors access to resources that are logically isolated from public internet traffic. The vulnerability aligns with CWE-918, which describes Server-Side Request Forgery (SSRF) flaws where server-side code makes requests to user-supplied URLs without proper validation. Furthermore, in terms of the MITRE ATT&CK framework, this exploitation technique maps to T1571, a non-standard port or protocol usage often employed by attackers to bypass network security controls and access internal resources that are not typically exposed on standard web ports.
To mitigate this vulnerability, organizations running YesWiki must immediately upgrade to version 4.6.7 or later, where the validateKeyIdUrl function has been patched to correctly identify and block these specific IPv6 address formats. In addition to upgrading, administrators should implement network-level controls such as egress filtering on web servers to restrict outbound connections to only known and necessary destinations. This defense-in-depth approach ensures that even if an application-layer vulnerability is exploited, the attacker cannot reach sensitive internal services or cloud metadata endpoints. Regular security audits of input validation logic are also recommended to prevent similar bypass techniques in other parts of the application codebase.