CVE-2026-104464 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains a server-side request forgery vulnerability that allows unauthenticated attackers to make server-side GET requests by supplying an unvalidated actor URL to the Bazar abonnements sync action. Attackers can target internal hosts or cloud metadata endpoints and chain attacker-controlled outbox first/next links, with fetched responses stored as readable Bazar entries.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
YesWiki versions prior to 4.6.7 are susceptible to a server-side request forgery vulnerability within the B abonnements sync action module. This flaw arises from insufficient validation of user-supplied input specifically regarding actor URLs provided during synchronization operations. The application fails to properly sanitize or restrict these URL parameters, allowing an unauthenticated attacker to dictate the destination and nature of HTTP GET requests initiated by the server itself. Unlike traditional cross-site request forgery which targets client-side sessions, this vulnerability leverages the server's own network privileges and trust relationships to perform actions on behalf of the application backend without user interaction or authentication credentials.
The technical mechanism involves an attacker supplying a maliciously crafted URL as part of the actor parameter in the Bazar abonnements sync endpoint. Because the framework processes this input directly into outgoing HTTP requests, it effectively becomes a proxy for arbitrary network access from the server's perspective. This capability is particularly dangerous because servers often reside within trusted internal networks or have access to cloud metadata services that are not exposed to external users. By targeting these internal endpoints, an attacker can probe the internal network topology, identify running services on localhost or private IP ranges, and potentially extract sensitive configuration data from infrastructure providers such as AWS EC2 instance metadata service or Azure managed identity endpoints.
The operational impact of this vulnerability extends beyond simple information disclosure due to the specific behavior of how fetched responses are handled within the YesWiki application logic. The system stores the content retrieved from these forged requests directly into readable Bazar entries. This means that data exfiltrated from internal hosts, such as database credentials, API keys, or private configuration files found in cloud metadata endpoints, is not merely logged but persisted in a publicly accessible format within the wiki structure. An attacker can chain multiple requests by manipulating outbox first and next links to automate the harvesting of sensitive information across various internal resources, turning a single injection point into a comprehensive data exfiltration vector that compromises confidentiality and integrity of both application data and underlying infrastructure secrets.
Mitigation strategies must prioritize immediate patching to version 4.6.7 or later where this input validation issue has been addressed by the developers. In environments where upgrading is not immediately feasible, network-level controls should be implemented to restrict outbound HTTP traffic from the web server host. This includes configuring firewalls to block access to cloud metadata endpoints which typically reside on link-local addresses such as 169.254.169.254 for AWS or similar ranges for other providers. Additionally, implementing strict allow-lists for any external services that the application is permitted to contact can prevent abuse of this functionality. Input validation at the application layer should enforce rigorous checking of URL schemes and domains, ensuring that only expected internal endpoints are accessible through administrative synchronization actions rather than exposing them to unauthenticated user input.
This vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF) as defined by the Common Weakness Enumeration standard, specifically reflecting flaws in insufficient validation of server-side requests. From a tactical perspective, it maps to MITRE ATT&CK technique T1557 Adversary-in-the-Middle and potentially T1046 Network Service Discovery if used for internal scanning. The persistence aspect where fetched data is stored as readable entries also touches upon aspects of data exfiltration techniques found in the ATT&CK framework, highlighting how application logic flaws can be chained to achieve significant security breaches beyond the initial injection point.