Description

YesWiki before 4.6.7 contains a cross-site request forgery vulnerability in the filemanager page handler, which deletes page attachments on GET requests without validating a CSRF token. Attackers can lure a logged-in page owner or administrator into a top-level GET navigation with do=del, erase, or emptytrash, deleting or permanently purging the page's attachments.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-10-02T12:17:16.840Z",
  "pubdate": "2026-10-02T12:17:16.840Z",
  "executiveSummary": "YesWiki versions prior to 4.6.7 are susceptible to a Cross-Site Request Forgery (CSRF) vulnerability residing within the filemanager page handler. This security flaw allows an unauthenticated remote attacker to perform unauthorized file system operations by tricking an authenticated user, such as a page owner or administrator, into visiting a specifically crafted URL. The vulnerability stems from the application's failure to enforce CSRF token validation on sensitive state-changing operations delivered via HTTP GET requests. Successful exploitation enables an attacker to invoke administrative actions, specifically the deletion or permanent purging of page attachments, without the victim's consent. This represents a significant integrity risk, as it allows for the malicious destruction of data associated with the wiki pages. The attack requires no prior knowledge of the target system's infrastructure beyond the victim's session validity and a mechanism to lure the victim into triggering the malicious navigation request. Mitigation requires upgrading the software to version 4.6.7 or later, where state-changing actions are properly secured against unauthorized requests.",
  "technicalDetails": "The vulnerability is located in the filemanager page handler component of YesWiki, which manages internal storage and attachment assets. The root cause is a deficiency in the request handling logic where sensitive operations—specifically those mapped to 'do=del', 'do=erase', and 'do=emptytrash'—are executed upon receipt of a standard HTTP GET request without the validation of a cryptographically secure, pseudo-random CSRF token or other non-predictable request parameter.\nBecause the filemanager handler treats GET requests as valid triggers for destructive operations, the application lacks the necessary authorization checks to confirm that the request was intentionally initiated by the user through the intended user interface. An attacker can exploit this by embedding a URL containing the destructive parameters within an <img> tag, an iframe, or by socially engineering a logged-in administrator to click a direct link. When the browser of the victim loads the resource, it automatically includes the victim's session cookies, authenticating the malicious request against the YesWiki backend.\nThe attack flow proceeds as follows: 1) The attacker crafts a malicious URL targeting the filemanager handler with one of the aforementioned parameters. 2) The attacker lures an authenticated administrator or page owner to the malicious payload via phishing or an external site. 3) The victim's browser makes an automatic GET request to the YesWiki application. 4) The application, failing to detect an anti-CSRF token, processes the request as a legitimate command. 5) The server-side logic executes the deletion or purging command on the file system, resulting in the permanent loss of attachments.\nThis vulnerability is restricted to environments where the victim has an active administrative or page-owner session. The exploitation is entirely network-accessible if the wiki is reachable by the attacker and the victim. Given that standard browsers permit cross-site navigation, the impact is high, as it bypasses authorization mechanisms entirely. The lack of idempotency in the GET-based design choice for state-changing operations effectively violates the principle that safe methods should not modify server-side state. The post-exploitation impact includes the loss of data availability and the destruction of sensitive or critical attachments, which cannot be recovered once purged from the trash via the 'emptytrash' operation."
}