Summary
YesWiki versions before 4.6.7 contain a cross-site request forgery vulnerability in the ajaxdeletepage handler. A malicious site or crafted link may cause a logged-in administrator or page owner to permanently delete an arbitrary page and associated content when the request is accepted without CSRF-token validation.
Affected context
The vulnerability occurs in YesWiki installations where the ajaxdeletepage handler accepts deletion requests through a GET request containing the expected callback parameter but does not require a valid CSRF token. The risk is greatest when an administrator or page owner is authenticated in the same browser and can be induced to visit attacker-controlled content.
Exploit preconditions
- Attack surface: The YesWiki page-deletion AJAX handler
- Required access: A victim must be authenticated with permissions to delete the targeted page
- Trigger point: A crafted cross-site request reaches the deletion handler through a GET request
- Why exploitation is possible: The handler does not verify a CSRF token before performing a destructive state-changing operation
Why this happens
The underlying bug is a missing server-side anti-CSRF check on a state-changing endpoint. The handler relies on the victim's existing authenticated session while accepting a cross-origin request, allowing another site to cause an action without the victim's intentional consent. This maps to CWE-352: Cross-Site Request Forgery (CSRF).
Potential impact
- An attacker may permanently delete arbitrary pages within the victim's permitted scope
- Associated ACLs, links, triples, comments, and referrers could also be removed
- Content availability and site structure may be disrupted
- Administrative or editorial workflows could be interrupted
- Recovery may require restoration from backups or other content-recovery processes
General mitigation guidance
Mitigation typically focuses on protecting every state-changing request with robust request-intent validation.
Common defensive patterns include:
- Requiring unpredictable, session-bound CSRF tokens for deletion and other mutating actions
- Rejecting state-changing operations delivered through GET requests
- Applying strict same-site and origin checks as defense-in-depth controls
- Requiring explicit authorization checks for the requested page and related objects
- Using least-privilege roles so page owners and administrators have only necessary deletion permissions
- Providing confirmation and recovery controls for destructive operations
- Treating callback parameters and other request values as untrusted input
How teams detect issues like this
Organizations can detect similar weaknesses through:
- Static analysis and code review searches for state-changing handlers that accept GET requests
- Checks for deletion or mutation paths that lack CSRF-token validation
- Dynamic testing that submits cross-origin requests while an authenticated session is active
- Web-application firewall or gateway policies monitoring unexpected cross-site requests to destructive endpoints
- Security tests that verify invalid, missing, expired, and session-mismatched tokens are rejected
- Automated review tools that flag destructive endpoints without explicit request-intent protections
