CVE-2026-104451 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains a cross-site request forgery vulnerability in RevisionsHandler that allows attackers to restore old page revisions through GET requests lacking CSRF token validation. Attackers can lure write-capable users into a top-level navigation with the restoreRevisionId parameter, silently overwriting current page content with stale or vandalized revisions.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The identified vulnerability in YesWiki versions prior to 4.6.7 represents a critical cross-site request forgery flaw within the RevisionsHandler component. This security deficiency stems from an inadequate implementation of anti-CSRF protections for specific administrative and maintenance operations, specifically the restoration of historical page revisions. The core technical failure lies in the server-side validation logic which fails to require or verify a valid CSRF token when processing GET requests that include the restoreRevisionId parameter. In secure web application design, state-changing actions such as modifying database records or overwriting file contents must be protected against unauthorized commands initiated by other sites. By allowing these sensitive operations via simple HTTP GET requests without additional authentication tokens, the application violates fundamental security principles regarding request integrity and user intent verification.
From an operational perspective, this vulnerability enables a sophisticated attack vector where malicious actors can manipulate write-capable users into executing unintended actions. An attacker constructs a deceptive link or embeds an image tag that triggers a GET request to the vulnerable endpoint with the specific restoreRevisionId parameter pointing to a target revision. When a user who possesses editing privileges for a wiki page clicks this link or loads the compromised page, their browser automatically sends the authenticated session cookies along with the forged request. The server processes this request as legitimate because it lacks any mechanism to distinguish between a user-initiated action and an automated forgery. Consequently, the current content of the targeted page is silently overwritten by the specified older revision, which may contain outdated information or maliciously inserted vandalism.
The impact of this vulnerability extends beyond simple data loss; it compromises the integrity and trustworthiness of the wiki platform. Since YesWiki is often used for collaborative knowledge bases where accuracy is paramount, the ability to revert pages without explicit user consent undermines the audit trail and version control reliability. Attackers can exploit this to deface websites, spread misinformation by restoring compromised historical versions, or disrupt ongoing projects by reverting recent work. The silent nature of the attack means that victims may not immediately realize their content has been altered until they review the page history or notice discrepancies in published information. This lack of immediate feedback exacerbates the potential for long-term damage to organizational reputation and data integrity.
This vulnerability aligns with CWE-352, which defines Cross-Site Request Forgery as a flaw where a malicious site causes a user's browser to perform an unwanted action on a trusted application that trusts the user's identity and cookies. Furthermore, in the context of the MITRE ATT&CK framework, this technique corresponds to T1078 Valid Accounts, specifically through the abuse of legitimate credentials via social engineering or automated forgery, and relates to T1499 Endpoint Denial of Service if used for persistent defacement. To mitigate this risk, developers must enforce strict CSRF token validation on all state-changing endpoints, particularly those handling revision control operations. Implementing SameSite cookie attributes set to Strict or Lax can also provide an additional layer of defense by preventing browsers from sending cookies in cross-site contexts. Additionally, switching sensitive actions like restoring revisions from GET requests to POST requests with required body data and token verification would significantly reduce the attack surface. Upgrading to YesWiki version 4.6.7 or later is essential as these versions include patches that address this specific validation gap.