Description

YesWiki before 4.5.3 contains multiple reflected cross-site scripting vulnerabilities that allow remote attackers to inject JavaScript through unsanitized parameters such as incomingurl, id, file, tags, and template. Attackers can lure authenticated or unauthenticated users into opening crafted links to hijack sessions and trigger authenticated requests against backend functionality.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.1",
  "pubDate": "2026-10-02T12:17:20.367Z",
  "pubdate": "2026-10-02T12:17:20.367Z",
  "executiveSummary": "YesWiki versions prior to 4.5.3 are susceptible to multiple reflected Cross-Site Scripting (XSS) vulnerabilities. These vulnerabilities arise from improper sanitization of user-supplied input across several parameters, including 'incomingurl', 'id', 'file', 'tags', and 'template'.\nAn unauthenticated remote attacker can exploit these flaws by crafting malicious URLs containing arbitrary JavaScript payloads. When a targeted user, whether authenticated or unauthenticated, clicks these links, the injected script executes within the context of the user's browser session.\nThe primary risk involves session hijacking, where an attacker may steal session cookies or tokens to gain unauthorized access to an authenticated user's account. Furthermore, attackers can perform unauthorized actions on behalf of the victim by triggering requests to backend administrative or functional endpoints. This vulnerability significantly compromises the confidentiality and integrity of user sessions and potentially backend system operations.",
  "technicalDetails": "The vulnerability resides in the application's handling of HTTP GET parameters, specifically 'incomingurl', 'id', 'file', 'tags', and 'template'. The application fails to adequately sanitize or encode these inputs before reflecting them back to the user within the HTML response. This failure facilitates the injection of arbitrary JavaScript code, which the browser interprets as legitimate script belonging to the target domain.\nThe exploitation flow begins with the attacker identifying the target application's URI parameters that are improperly reflected. The attacker crafts a malicious URL containing a JavaScript payload within one of the vulnerable parameters. For example, by manipulating the 'incomingurl' or 'id' parameter to include script tags or event handlers, the attacker constructs a delivery mechanism. The attacker then lures a victim to click this link through social engineering or other vectors.\nUpon clicking the link, the victim's browser initiates a request to the YesWiki application with the malicious payload included in the query string. The server processes the request and embeds the unsanitized input directly into the HTTP response body. When the victim's browser renders this response, it executes the injected JavaScript code in the security context of the origin domain. Because the vulnerability does not require authentication to exploit, it exposes all application users to the risk of attack.\nSuccessful execution of the script allows the attacker to perform actions such as stealing session identifiers (e.g., session cookies), which can be transmitted to an attacker-controlled server. This enables full account takeover if the victim has an active, privileged session. Additionally, the injected script can be used to perform cross-site request forgery (CSRF) by triggering authenticated requests against the application's backend functionality, effectively bypassing CSRF protections if the victim's session is active, or exploiting administrative functions if an administrator is targeted. The vulnerability affects YesWiki versions before 4.5.3."
}