Description

YesWiki before 4.6.7 contains a blind server-side request forgery vulnerability that allows unauthenticated attackers to make arbitrary server-side requests via the idtypeannonce parameter of /api/entries/bazarlist. Because isValidURL() always returns true, attackers can supply internal URLs fetched by curl in loadURLContent() to probe internal networks and reach internal services or metadata endpoints.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-10-02T12:17:14.837Z",
  "pubdate": "2026-10-02T12:17:14.837Z",
  "executiveSummary": "YesWiki versions prior to 4.6.7 are susceptible to a blind Server-Side Request Forgery (SSRF) vulnerability. The flaw exists within the /api/entries/bazarlist endpoint, specifically involving the idtypeannonce parameter.\nThe vulnerability allows an unauthenticated, remote attacker to coerce the host server into performing arbitrary HTTP requests. By abusing the flawed validation logic, an attacker can pivot through the server to interact with internal network resources, private services, or cloud-based metadata APIs that are otherwise unreachable from the public internet.\nThe root cause is a validation failure in the application's URL verification mechanism. Because the isValidURL() function fails to perform adequate sanitation or allow-listing, it returns a boolean true for malicious inputs, permitting the backend curl request in loadURLContent() to process attacker-supplied URIs.\nThis vulnerability poses a significant risk to the integrity and confidentiality of internal infrastructure, as it enables reconnaissance, port scanning, and interaction with internal-only services. Exploitation does not require prior authentication or elevated privileges, making it a critical threat to unpatched instances of YesWiki.",
  "technicalDetails": "The vulnerability resides within the /api/entries/bazarlist endpoint of the YesWiki application. The application processes the idtypeannonce parameter without sufficient validation, allowing an attacker to inject arbitrary URLs into the request processing lifecycle.\nThe core issue stems from the flawed implementation of the isValidURL() function, which serves as a security gate for external resource fetching. During execution, this function consistently evaluates to true regardless of the input provided. This failure enables the bypass of security checks intended to restrict outgoing requests to trusted or expected domains.\nThe subsequent execution flow involves the loadURLContent() function, which utilizes a server-side curl instance to fetch the content from the provided URI. When the idtypeannonce parameter contains an attacker-controlled internal address (e.g., http://127.0.0.1 or http://169.254.169.254), the server initiates the request on behalf of the attacker.\nBecause the SSRF is blind, the attacker does not necessarily see the response content, but can observe timing differences or potential side effects to confirm successful interactions with the target infrastructure. The attack flow is as follows: 1) An unauthenticated attacker crafts a malicious request to /api/entries/bazarlist, injecting the target URL into the idtypeannonce parameter. 2) The server passes this URL to isValidURL(), which incorrectly validates the input. 3) The server calls loadURLContent(), which instructs the underlying curl library to perform the request to the designated internal resource. 4) The internal service processes the request, potentially revealing sensitive information or executing administrative actions based on the server's trusted identity within the network.\nThis vulnerability effectively elevates the attacker's position from the public internet to the internal network boundary, facilitating reconnaissance of internal services, bypassing firewall rules, and potentially accessing sensitive cloud instance metadata services. The lack of authentication requirements significantly increases the attack surface, allowing automated scanning and exploitation by unauthorized remote actors."
}