CVE-2026-104444 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains an authorization bypass vulnerability in the comments API editComment route that allows authenticated low-privilege users to overwrite arbitrary pages or comments by supplying their own page as the pagetag field. Attackers can send a POST request to the api/comments endpoint targeting a victim tag, bypassing per-page write ACLs to replace content and reparent existing pages or comments.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in YesWiki versions prior to 4.6.7 represents a critical authorization bypass within the application's comment management subsystem. Specifically, this flaw resides in the editComment route of the API interface, which is designed to handle updates to user-generated content such as comments and page edits. The core technical deficiency lies in how the backend processes the pagetag parameter during these update operations. Instead of strictly validating that the provided pagetag corresponds to a resource for which the authenticated user possesses explicit write permissions, the application fails to enforce access control checks effectively when this field is manipulated by the client side. This oversight allows an attacker who has already achieved authentication with low-privilege credentials to bypass per-page Access Control Lists (ACLs) that are intended to restrict modification rights to specific roles or users.
From a technical perspective, the exploitation mechanism involves sending a crafted POST request to the api/comments endpoint. The attacker specifies their own page identifier in the pagetag field while targeting a victim's tag as the primary target of the operation. Because the server trusts this client-supplied parameter without sufficient validation against the user's actual permissions for that specific resource, it proceeds with the update or reparenting action. This logic error effectively neutralizes the security boundary established by the ACLs, allowing low-privilege users to overwrite arbitrary pages or comments on behalf of higher-privileged accounts or simply deface content they should not be able to modify. The ability to reparent existing pages further complicates the integrity of the wiki structure, potentially leading to data loss or unauthorized restructuring of site navigation and hierarchy.
The operational impact of this vulnerability is significant for any deployment relying on YesWiki for collaborative editing where strict role-based access control is enforced. An attacker can achieve arbitrary code execution if they manage to inject malicious scripts into pages that are subsequently rendered by other users, leading to Cross-Site Scripting (XSS) attacks. Beyond XSS, the ability to overwrite content undermines data integrity and trust in the platform. In enterprise or public-facing deployments, this could result in defacement, misinformation dissemination, or disruption of services. The vulnerability essentially allows a low-privilege user to escalate their effective privileges regarding write operations across the entire wiki instance, violating the principle of least privilege that underpins secure system design.
This flaw is categorized under CWE-269, which refers to Improper Privilege Control, as it involves an actor obtaining more access or system functionality than intended. Additionally, from a tactical perspective aligned with MITRE ATT&CK frameworks, this vulnerability facilitates the T1078 Valid Accounts technique, where attackers use legitimate credentials to gain initial access and then leverage privilege escalation techniques such as T1068 Exploitation for Privilege Escalation or T1495 Infiltrate Remote Systems if combined with other vectors. The specific action of overwriting content aligns with the Impact category in ATT&CK, particularly data manipulation objectives like Data Manipulation (T1565) or Defacement (T1491).
To mitigate this vulnerability, organizations running YesWiki must immediately upgrade to version 4.6.7 or later, where the developers have addressed the authorization logic flaws in the editComment route. For environments that cannot be patched instantly due to compatibility constraints, a temporary workaround involves implementing strict server-side validation of all pagetag parameters against the authenticated user's ACLs before processing any write requests. This can be achieved by deploying a Web Application Firewall (WAF) rule set that inspects POST payloads for suspicious patterns in API calls and blocks attempts where the requested resource does not match the user's permission scope. Regular security audits focusing on input validation and access control enforcement are also recommended to prevent similar logic flaws from being introduced during future development cycles.