CVE-2026-104448 in YesWiki
Summary
by MITRE • 10/02/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
YesWiki versions prior to 4.6.7 are susceptible to a critical cross-site request forgery vulnerability within the ajaxdeletepage handler. This flaw stems from an insufficient validation of incoming requests, specifically allowing state-changing operations to be executed without verifying the presence or validity of anti-CSRF tokens. The vulnerability is triggered when a GET request includes a jsonp_callback parameter, which indicates that the server expects a JSONP response format. In this specific context, the application fails to enforce standard security controls typically associated with POST requests or authenticated state changes, thereby creating an exploitable pathway for unauthorized actions.
The technical mechanism of exploitation relies on the browser's automatic inclusion of session cookies and authentication credentials when making cross-origin requests. An attacker can construct a malicious URL that targets the ajaxdeletepage endpoint while embedding the required jsonp_callback parameter. When a victim who is currently authenticated as an administrator or page owner visits this crafted link, either by clicking it directly or through other social engineering techniques such as embedded images in emails or forums, their browser will automatically send the request along with valid session cookies. The server processes this GET request and executes the deletion logic because it does not check for a CSRF token, treating the unauthenticated-looking GET request as legitimate due to the presence of valid credentials.
The operational impact of this vulnerability is severe, resulting in permanent data loss and potential privilege escalation effects within the wiki environment. Upon successful exploitation, arbitrary pages are deleted from the system. This deletion process is not limited to just the page content; it cascades to remove associated access control lists that define user permissions, hyperlinks connecting other parts of the site, RDF triples used for semantic web data integrity, comments attached to the pages, and referrer records. The loss of ACLs can disrupt organizational workflows by removing necessary restrictions or granting unintended access if not properly restored from backups. Furthermore, the destruction of links and triples compromises the structural integrity and navigability of the wiki, potentially rendering large sections of documentation inaccessible or broken for other users.
This vulnerability aligns with CWE-352, which describes Cross-Site Request Forgery (CSRF), specifically highlighting the failure to verify user intent through tokens before performing state-changing operations. From a threat modeling perspective using the MITRE ATT&CK framework, this exploit falls under T1078 Valid Accounts and potentially T1496 Endpoint Denial of Service if used maliciously against critical documentation repositories. The attack vector is classified as remote with low complexity, requiring only user interaction to trigger the payload via a crafted link.
To mitigate this vulnerability, administrators must upgrade YesWiki to version 4.6.7 or later where these checks have been implemented. In environments where immediate upgrading is not feasible, temporary mitigations include restricting access to the ajaxdeletepage endpoint through web application firewall rules that block GET requests containing jsonp_callback parameters targeting deletion endpoints. Additionally, implementing strict Content Security Policy headers can help prevent some forms of script injection that might facilitate more complex CSRF chains, although direct token validation on the server side remains the primary and most effective defense against this specific flaw. Regular audits of authentication handlers for state-changing operations are recommended to ensure no similar gaps exist in other parts of the application logic.