Summary
YesWiki before version 4.6.7 contains a server-side request forgery vulnerability in the public forms actor inbox route. An unauthenticated attacker may send signed Follow activities that cause the server to issue blind GET or POST requests to internal services, including cloud metadata endpoints.
Affected context
The vulnerability occurs in YesWiki deployments exposing the public forms actor inbox route and processing signed Follow activities. Risk is present when attacker-controlled actor URLs are accepted as request destinations without sufficient validation, allowing the server to access network locations that are not directly reachable by the attacker.
Exploit preconditions
- Attack surface: The publicly accessible forms actor inbox route - Required access: No authenticated YesWiki account is required - Trigger point: Processing a signed Follow activity - Attacker-controlled input: The activity body supplies an internal actor URL - Why exploitation is possible: The server may use the supplied URL to make
outbound GET or POST requests without adequately restricting destination
hosts, networks, schemes, or redirects
Why this happens
The underlying issue is server-side request forgery, mapped to CWE-918. The application treats a URL supplied through an externally controlled activity as a trusted destination for server-side network requests. When destination validation and network-layer restrictions are insufficient, the application can be induced to contact internal hosts or cloud metadata services on an attacker's behalf.
Potential impact
- An attacker may probe internal network services through blind requests.
- The server could reach administrative interfaces that are not publicly exposed.
- Cloud instance metadata or temporary credentials could be disclosed.
- Internal services could receive unintended GET or POST requests.
- The vulnerability could support follow-on compromise or lateral movement.
General mitigation guidance
Mitigation generally focuses on reducing trust in user-supplied URLs and enforcing outbound request boundaries. Common defensive patterns include using strict allowlists for permitted destinations, rejecting private, loopback, link-local, and reserved address ranges, restricting accepted schemes and ports, and validating resolved addresses after DNS resolution. Redirects should be disabled or revalidated, and outbound traffic should be constrained with network egress controls. Services should use least-privilege identities, while cloud environments should limit metadata access and protect sensitive credentials. Secure-by-default request clients and centralized URL validation reduce inconsistent enforcement across routes.
How teams detect issues like this
Detection approaches include static analysis for request functions that accept URLs from activity bodies or other untrusted inputs, code review for missing destination allowlists and redirect validation, and testing of private, loopback, link-local, reserved, and DNS-rebinding targets. Monitor outbound requests from the application for unusual internal destinations, metadata endpoint access, unexpected methods, and anomalous request volumes. Policy enforcement can require approved egress paths and centralized SSRF-safe HTTP clients; automated security review tools may help identify risky URL flows.
