Description

YesWiki before 4.6.7 contains a cross-site request forgery vulnerability in the ajaxdeletepage handler, which permanently deletes a page on any GET request carrying a jsonp_callback parameter without checking a CSRF token. Attackers can lure a logged-in administrator or page owner to a crafted link to delete arbitrary pages along with their ACLs, links, triples, comments and referrers.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-10-02T12:17:16.163Z",
  "pubdate": "2026-10-02T12:17:16.163Z",
  "executiveSummary": "YesWiki versions prior to 4.6.7 are susceptible to a Cross-Site Request Forgery (CSRF) vulnerability within the ajaxdeletepage handler.\nThe vulnerability allows an unauthenticated attacker to induce a privileged user, such as an administrator or page owner, to perform unauthorized state-changing actions.\nBy tricking a victim into clicking a crafted URL, an attacker can cause the permanent deletion of arbitrary pages, including associated ACLs, links, triples, comments, and referrers.\nThe core of the issue lies in the application's failure to enforce CSRF token validation for requests directed at the delete handler, rendering session-based authentication insufficient to protect against forged requests.\nThe exploit relies on the victim maintaining an active session with the application, as the server treats GET requests containing a jsonp_callback parameter as legitimate deletion triggers regardless of the origin of the request.\nSuccessful exploitation results in significant data loss and denial of service for the deleted resources, with no requirement for the attacker to possess elevated privileges on the target system.",
  "technicalDetails": "The vulnerability resides in the ajaxdeletepage handler of YesWiki, which processes requests for page deletion. The handler fails to implement adequate CSRF protection mechanisms, such as anti-CSRF tokens, to verify the intent of incoming requests.\nThe application logic treats a GET request as sufficient to invoke the deletion routine if the request includes a jsonp_callback parameter. This design flaw allows an attacker to trigger the function by crafting a malicious URI that initiates the deletion process.\nThe attack flow begins when an attacker lures an authenticated administrator or page owner to a resource controlled by the attacker (e.g., an HTML page containing an hidden image tag, an iframe, or a standard link targeting the vulnerable YesWiki URL).\nBecause the YesWiki session cookie is automatically included by the browser during this cross-site request, the server identifies the request as authenticated and proceeds with the execution of the ajaxdeletepage handler.\nUpon execution, the handler permanently removes the target page and all associated metadata, including Access Control Lists (ACLs), internal links, semantic triples, user-generated comments, and inbound referrers.\nThe lack of validation for the HTTP request method—specifically the reliance on GET for a state-changing operation—is a critical security deficiency. By design, GET requests should be idempotent and must not perform destructive actions, yet the implementation of the jsonp_callback logic circumvents this standard security principle.\nThe vulnerability is present in all versions of YesWiki prior to 4.6.7. An attacker does not require direct access to the administrative panel; they only need the ability to deliver a malicious link to a logged-in user with sufficient deletion permissions.\nOnce the request is successfully triggered, the damage is immediate and permanent, resulting in the loss of critical application content and secondary configuration data linked to the deleted page.\nThe use of the jsonp_callback parameter essentially forces the application to treat the request as a cross-origin data retrieval, which is then abused to perform destructive actions under the security context of the victim's session."
}