CVE-2026-104449 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains an access control vulnerability allowing unauthenticated attackers to overwrite any existing wiki page, including pages whose write ACL restricts editing, via the Bazar entry-creation flow. Attackers can submit a crafted entry with an attacker-controlled id_fiche matching an existing page, overwriting its body for mass defacement and content destruction.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in YesWiki versions prior to 4.6.7 represents a critical failure in access control mechanisms within the Bazar module's entry-creation workflow. This flaw allows unauthenticated attackers to bypass standard authentication requirements and modify existing wiki pages, regardless of their configured write Access Control Lists (ACLs). The core technical issue stems from insufficient validation of input parameters during the creation process for new entries. Specifically, when a user submits an entry through the Bazar interface, the system fails to adequately verify whether the provided identifier matches an existing page that is protected by restrictive permissions. This oversight enables malicious actors to exploit the id_fiche parameter, which serves as the unique identifier for wiki pages within the application's database structure.
By submitting a crafted HTTP request containing an attacker-controlled value for the id_fiche field that corresponds to an already existing page ID, the attacker can trick the backend processing logic into treating the new entry submission as an update operation rather than a creation one. Consequently, the system overwrites the body content of the targeted wiki page with the data provided in the request. This behavior occurs even if the target page has strict ACL settings that explicitly deny editing rights to unauthenticated users or specific user groups. The vulnerability effectively neutralizes the intended security controls designed to protect sensitive or restricted information within the wiki environment, allowing for unauthorized modification of content that should remain immutable under normal operational conditions.
The operational impact of this access control bypass is significant, primarily manifesting as mass defacement and potential data destruction. Attackers can alter critical documentation, inject malicious scripts into page bodies if cross-site scripting vectors are present in other parts of the application, or simply delete important information by overwriting it with empty or destructive content. This capability undermines the integrity and reliability of the wiki platform, which is often used for collaborative knowledge management where trust in data accuracy is paramount. Furthermore, because the attack requires no authentication, it can be executed remotely against any instance running a vulnerable version without prior access credentials, increasing the likelihood of successful exploitation by opportunistic attackers scanning for exposed instances.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management and CWE-434 Unrestricted Upload of File with Dangerous Type if file upload components are involved in the entry creation flow, though the primary issue is strictly related to authorization logic failures. In terms of adversary tactics, this exploit maps to MITRE ATT&CK technique T1082 System Information Discovery or more accurately T1565 Data Manipulation, as it involves unauthorized modification of stored data. To mitigate this risk, administrators must upgrade YesWiki to version 4.6.7 or later where the access control checks have been strengthened to properly validate user permissions before processing any page updates via the Bazar module. Additionally, implementing strict input validation on all identifier fields and ensuring that backend logic distinguishes clearly between creation and update operations based on both parameter values and current session privileges is essential for securing similar applications against unauthorized modifications.