CVE-2026-104447 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains a cross-site request forgery vulnerability in the autoupdate UpdateAction that allows attackers to delete installed packages via unprotected GET requests. Attackers can lure a logged-in administrator to a crafted link with action=delete and a package parameter to remove extensions like bazar, breaking core site functionality.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/02/2026
The security flaw identified in YesWiki versions prior to 4.6.7 represents a critical cross-site request forgery vulnerability located within the autoupdate UpdateAction component of the application architecture. This weakness stems from an insufficient validation mechanism for incoming HTTP requests, specifically targeting endpoints that are designed to manage installed packages and extensions. The core technical deficiency lies in the fact that these sensitive administrative operations are exposed through unprotected GET requests rather than being restricted to POST or PUT methods with appropriate anti-CSRF token verification. In a secure implementation, state-changing actions such as deleting software components should require explicit user intent confirmation via form submissions protected by unique session tokens. By allowing deletion commands to be executed via simple URL parameters, the application fails to distinguish between legitimate administrative actions initiated by the site owner and malicious requests crafted by an external attacker.
The operational impact of this vulnerability is severe because it directly compromises the integrity and availability of the web platform. An attacker can exploit this flaw by constructing a malicious link that includes specific query string parameters indicating action=delete along with a target package identifier, such as bazar or other critical extensions. When a logged-in administrator clicks on this crafted URL while authenticated to their YesWiki instance, the browser automatically attaches any existing session cookies to the request due to standard HTTP behavior. The server then processes this request as if it were authorized by the legitimate user, resulting in the immediate and unauthorized removal of the specified package from the system. This action is not reversible without manual reinstallation and configuration restoration, leading to significant downtime and potential data loss depending on the functionality provided by the deleted extension.
From a classification perspective, this vulnerability aligns with CWE-352, which describes Cross-Site Request Forgery (CSRF), specifically highlighting the failure to verify that state-changing requests are initiated by the legitimate user. Furthermore, it relates to CWE-614 regarding insufficient session identification in URLs and potentially CWE-918 for Server-Side Request Forgery if the deletion triggers external network calls during package removal processes. In terms of offensive security frameworks, this exploit maps to MITRE ATT&CK technique T1557, which covers Adversary-in-the-Middle scenarios where attackers intercept or manipulate traffic, although in this specific case, it is more accurately described as a direct exploitation of trust relationships (T1098.004 for SSH Authorized Key Manipulation analogs applied to web session hijacking contexts) and T1556 for modifying authentication processes by bypassing them entirely through CSRF. The attacker does not need to steal credentials or inject scripts into the page, but rather relies on the victim's active authenticated state to perform destructive actions silently in the background of their browsing activity.
To mitigate this vulnerability, immediate remediation steps must focus on enforcing strict HTTP method restrictions and implementing robust anti-CSRF protections for all administrative endpoints. Developers should ensure that any action resulting in a change to server-side state, such as deleting packages or modifying configurations, is exclusively accessible via POST requests rather than GET. Additionally, the implementation of synchronized CSRF tokens within forms and AJAX requests is essential to verify that each request originates from an authorized source linked to the current user session. It is also advisable to implement double-submit cookie patterns where a random token stored in a cookie must match one submitted in the form data or headers. For existing deployments running versions before 4.6.7, upgrading to the patched version is the primary recommendation as it addresses these architectural flaws at the code level. Until an upgrade can be performed, administrators should consider implementing web application firewall rules that monitor for unusual patterns of GET requests targeting update endpoints and restrict access to administrative interfaces based on IP whitelisting or multi-factor authentication requirements where possible.