CVE-2026-104452 in YesWiki
Summary
by MITRE • 10/02/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in YesWiki versions prior to 4.6.7 represents a critical failure in access control mechanisms within the filemanager module. Specifically, this is an unvalidated cross-site request forgery (CSRF) flaw that affects operations involving the deletion of page attachments. The core technical issue lies in the implementation of the GET request handler for specific actions such as do=del, erase, and emptytrash. In a secure application architecture, state-changing operations like deleting files or purging trash should never be triggered by simple HTTP GET requests without additional verification mechanisms. Instead, these actions are typically reserved for POST requests accompanied by anti-CSRF tokens to ensure that the request originates from an authorized user intent rather than being forged by a malicious third party. By allowing these destructive actions via GET parameters, YesWiki violates fundamental web security principles regarding idempotency and state change protection.
From a technical perspective, this flaw allows attackers to craft malicious URLs or embed them within images on other websites that trigger the deletion of attachments when viewed by an authenticated user. Since modern browsers automatically include session cookies with every request made to the same origin, any GET request initiated from a different domain will still carry the victim's authentication credentials if they are currently logged into YesWiki. Consequently, when the victim clicks a link or loads a page containing the malicious payload, their browser sends the DELETE command along with valid session data. The server processes this request as legitimate because it lacks any mechanism to verify that the user explicitly intended to perform this action on that specific site instance. This bypasses standard CSRF protections which rely on synchronizer tokens embedded in forms or custom headers for POST requests.
The operational impact of this vulnerability is significant, particularly regarding data integrity and availability. An attacker who successfully exploits this flaw can cause unauthorized deletion of page attachments, leading to the loss of important documents, images, or other files associated with YesWiki pages. In more severe cases, using the emptytrash action allows for the permanent purging of deleted items that might otherwise be recoverable from a trash bin. This constitutes a denial of service against data availability and represents an integrity violation where unauthorized actors can alter system state without permission. For administrators or page owners who maintain critical content on their wikis, this vulnerability poses a direct threat to business continuity and record retention policies.
This vulnerability aligns with CWE-352, which describes Cross-Site Request Forgery (CSRF), specifically highlighting the failure to verify user intent for state-changing operations. It also maps to MITRE ATT&CK technique T1076, known as Remote File Inclusion using Web Protocols, although in this context it is more accurately described under privilege escalation or data manipulation tactics where an attacker leverages trusted sessions to perform unauthorized actions. The exploitation vector falls under the category of client-side attacks that abuse server trust in user-initiated requests.
To mitigate this vulnerability, developers must enforce strict HTTP method restrictions for state-changing operations. Actions such as deleting attachments or emptying trash should be implemented using POST requests rather than GET requests. Furthermore, it is essential to implement robust CSRF token validation on all forms and AJAX calls that modify server-side data. These tokens should be unique per session and validated upon receipt of the request to ensure they were generated by the application itself for the specific user making the request. Additionally, implementing SameSite cookie attributes can provide an additional layer of defense by restricting how browsers send cookies in cross-site contexts, thereby reducing the effectiveness of CSRF attacks even if other controls are bypassed. Upgrading to YesWiki version 4.6.7 or later resolves this issue as it includes these necessary security hardening measures.