CVE-2026-116204 in YesWiki
Summary
by MITRE • 10/25/2026
YesWiki before 4.7.0 contains a cross-site request forgery vulnerability in the despam action (tools/security/actions/despam.php) that lets unauthenticated attackers delete or restore pages through an administrator's session. Attackers can plant an auto-submitting raw HTML form on a wiki page, so an administrator who views it posts clean, suppr[], or rev[] parameters that delete PagePrincipale, configuration pages, or overwrite current content.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified in YesWiki versions prior to 4.7.0 represents a critical cross-site request forgery flaw within the despam administrative action located at tools/security/actions/despam.php. This security defect allows unauthenticated attackers to manipulate state-changing operations by exploiting the trust that an application places in user sessions, specifically targeting administrators who have authenticated access to the wiki platform. The core technical failure lies in the absence of robust anti-CSRF tokens or validation mechanisms within the despam action endpoint, which processes requests without verifying their origin integrity against a secure session identifier.
An attacker can exploit this vulnerability by embedding an auto-submitting HTML form directly into a visible page on the wiki. When an administrator with sufficient privileges views this compromised page, their browser automatically submits the forged request to the server using the administrator's active session cookies. The malicious payload includes specific parameters such as clean[], suppr[], and rev[] which dictate the action taken by the despam module. Because the server validates only the presence of a valid administrative session rather than the legitimacy of the request source, it executes these commands as if they were initiated by the legitimate administrator.
The operational impact of this vulnerability is severe due to its potential for complete system compromise and data integrity loss. By manipulating the suppr[] parameter, an attacker can force the deletion of critical pages such as PagePrincipale or essential configuration files that govern the wiki's structure and settings. Alternatively, using the rev[] parameter allows attackers to overwrite current content with malicious text or code, effectively defacing the site or injecting persistent malware payloads into trusted documentation. This capability undermines the fundamental trust model of collaborative platforms where administrators rely on automated spam filtering tools without suspecting they can be weaponized against them.
From a classification perspective, this vulnerability aligns with CWE-352 Cross-Site Request Forgery (CSRF), which describes situations where an application uses a user's authenticated credentials to perform unintended actions. In the context of the MITRE ATT&CK framework, this attack vector corresponds to T1078 Valid Accounts and potentially T1499 Endpoint Denial of Service if deletion leads to service unavailability, though its primary classification remains under unauthorized modification or destruction of data via trusted administrative interfaces. The lack of request origin verification is a common oversight in legacy web applications that prioritize convenience over rigorous input validation for state-changing operations.
To mitigate this vulnerability, immediate patching to YesWiki version 4.7.0 or later is required as it addresses the underlying security flaws in the despam action. For environments where upgrading is not immediately feasible, implementing strict CSRF protection mechanisms such as synchronizer token patterns is essential. This involves generating unique, unpredictable tokens per session and validating them on every state-changing request to ensure they originate from legitimate application pages rather than external sources. Additionally, enforcing SameSite cookie attributes can prevent browsers from sending session cookies in cross-site requests, providing an additional layer of defense against CSRF attacks even if the application logic is not immediately updated.