Summary
YesWiki contains a cross-site request forgery vulnerability in the autoupdate UpdateAction, where an unprotected GET request can delete installed packages. If a logged-in administrator visits a crafted link, an attacker may remove extensions and disrupt core site functionality.
Affected context
The vulnerability occurs in YesWiki installations that expose the autoupdate UpdateAction and accept package-deletion requests through GET parameters without an effective request-integrity check. Risk is highest when an administrator is authenticated in the same browser and can be induced to follow an attacker-controlled link.
Exploit preconditions
- Attack surface: The YesWiki autoupdate action handling package-management requests
- Required access: A logged-in administrator must have an active authenticated session
- Trigger point: A crafted request containing the package-deletion action and a target package parameter
- Why exploitation is possible: The state-changing operation is reachable through an unprotected GET request without sufficient CSRF validation
Why this happens
The underlying bug is a missing request-integrity control on a state-changing administrative action. Because the application accepts a deletion request through a browser-mediated GET request without verifying that it originated from the intended site, another site can cause the administrator's browser to submit the request automatically. This behavior maps to CWE-352: Cross-Site Request Forgery.
Potential impact
- Installed extensions may be deleted without the administrator's deliberate consent
- Core site functionality may be disrupted
- The affected YesWiki instance could experience denial of service
- Administrative trust and site availability may be reduced
- Repeated or targeted requests could cause broader configuration or content disruption
General mitigation guidance
Mitigation generally focuses on ensuring that every state-changing administrative operation requires explicit request authorization.
Common defensive patterns include:
- Requiring unpredictable, session-bound anti-CSRF tokens for state-changing requests
- Avoiding GET requests for destructive operations and using appropriately protected methods instead
- Validating the intended action, target resource, and authorization on the server side
- Applying suitable SameSite cookie policies and checking relevant request-origin signals as defense in depth
- Restricting package-management capabilities according to least privilege
- Providing confirmation workflows for destructive administrative actions
How teams detect issues like this
Organizations can look for CSRF exposure through:
- Static analysis rules identifying destructive operations reachable through GET handlers
- Code review signals such as missing CSRF-token validation on administrative routes
- Tests that submit state-changing requests without valid request-integrity tokens
- Web logs showing package-deletion actions initiated from unusual referrers or unexpected browsing patterns
- Policy enforcement requiring CSRF protection for all browser-accessible state-changing endpoints
Automated application-security testing and code-review tools may help identify unprotected administrative actions.
