Summary
YesWiki before 4.6.7 contains a server-side request forgery issue in the Bazar valeur action, where page editors can cause the server to request attacker-selected URLs. The response may also be inserted as unescaped HTML, allowing scripts to run in the browsers of users who view the affected page.
Affected context
The vulnerability may occur in YesWiki installations that expose the Bazar valeur action to page editors and use its url parameter to retrieve remote content. Risk increases when the server can reach loopback addresses, private network services, or cloud metadata endpoints, and when fetched responses are rendered without context-appropriate HTML escaping.
Exploit preconditions
- Attack surface: The Bazar valeur action and its URL-fetching behavior
- Required access: Permission to create or edit a page that invokes the affected action
- Network condition: The YesWiki server must be able to reach the selected internal or external URL
- Trigger point: Processing the supplied url parameter and rendering the retrieved content
- Why exploitation is possible: Server-side requests are insufficiently restricted, and returned content may be inserted into a viewer's page without adequate output encoding
Why this happens
The issue combines insufficient server-side request validation with unsafe handling of fetched HTML. A user-controlled URL is accepted as a server request target without sufficiently constraining destination classes such as loopback or private addresses, which is characteristic of SSRF and related to CWE-918. The retrieved response is then rendered without context-appropriate escaping, allowing active markup or scripts to reach a browser; this behavior maps to CWE-79: Improper Neutralization of Input During Web Page Generation.
Potential impact
- Internal services may be probed or exposed
- Sensitive responses from reachable endpoints could be disclosed
- Cloud or infrastructure metadata may be accessed where network policy permits
- Scripts could execute in the browsers of users viewing affected pages
- User sessions or page content may be manipulated through client-side code
General mitigation guidance
Mitigation generally focuses on reducing trust in user-supplied URLs and treating remote responses as untrusted data.
Common defensive patterns include:
- Allowing requests only to an explicit, narrowly defined destination allowlist
- Blocking loopback, link-local, private, and other restricted address ranges after DNS resolution
- Applying outbound network policies that limit the server's reachable services
- Using safe fetch behavior with strict schemes, ports, redirects, timeouts, and response-size limits
- Encoding fetched content for its actual output context or rendering it as inert text rather than active HTML
- Applying least privilege to the web process and page-editing roles
- Separating trusted page content from editor-controlled remote content
How teams detect issues like this
Detection can combine application review, runtime monitoring, and policy enforcement:
- Use static analysis to identify user-controlled URL parameters passed to server-side HTTP clients
- Review code for missing private-address checks, unrestricted redirects, and unsafe HTML insertion
- Search templates and rendering paths for raw response insertion without context-aware encoding
- Monitor outbound requests from the application to loopback, private, link-local, and metadata-related destinations
- Enforce allowlists and egress policies at the application or network layer
- Use automated security review tools to flag SSRF sinks and browser-facing output that bypasses encoding
