Summary
YesWiki contains a server-side request forgery vulnerability in the Bazar subscriptions synchronization action. An unauthenticated attacker may provide an unvalidated actor URL to make the server issue GET requests to internal services or cloud metadata endpoints, with retrieved responses potentially stored as readable Bazar entries.
Affected context
The issue occurs in YesWiki deployments using the Bazar subscriptions synchronization functionality when actor-supplied URLs are accepted without adequate destination validation. Risk is greater where the application can reach internal administrative services, cloud metadata endpoints, or other protected network locations, and where synchronized responses are subsequently persisted in readable entries.
Exploit preconditions
- Attack surface: The Bazar subscriptions synchronization action
- Required access: No authentication may be required when the affected action is exposed
- Trigger point: Submission or processing of an attacker-controlled actor URL and related outbox links
- Why exploitation is possible: The server performs outbound GET requests without sufficiently restricting destinations, and fetched responses may be stored for later access
Why this happens
The vulnerability results from treating externally supplied URLs as trusted destinations for server-side HTTP requests. Without strict validation of schemes, hosts, resolved addresses, redirects, and chained links, the application can be induced to access resources from protected network locations. This behavior maps to CWE-918: Server-Side Request Forgery, where an attacker influences a server to send requests on the attacker's behalf.
Potential impact
- An attacker may access internal HTTP services
- Cloud instance metadata or temporary credentials could be exposed
- Responses from protected endpoints could be stored in readable Bazar entries
- Internal network topology or service details could be disclosed
- Attackers could use chained links to broaden the set of reachable destinations
General mitigation guidance
Mitigation generally focuses on reducing trust in user-controlled URLs and enforcing outbound request policy.
Common defensive patterns include:
- Allowing only explicitly approved schemes, hosts, ports, and URL destinations
- Resolving hostnames and rejecting private, loopback, link-local, and reserved address ranges
- Revalidating every redirect and chained outbox link
- Applying egress filtering and network segmentation around application workloads
- Preventing sensitive response bodies from being persisted in broadly readable entries
- Running the application with least-privilege network and cloud permissions
- Using secure-by-default HTTP client settings with bounded timeouts and response sizes
How teams detect issues like this
Organizations can look for SSRF risks through:
- Static analysis rules identifying HTTP clients fed by request parameters or imported feed links
- Code review checks for missing URL allowlists, redirect validation, and private-address blocking
- Tests covering DNS rebinding, redirects, IPv4 and IPv6 representations, and chained links
- Network monitoring for unexpected requests from application hosts to metadata services or internal ranges
- Egress policies that alert on or block unauthorized destinations
- Automated security review tools that flag user-controlled URL usage without destination controls
