CVE-2026-116821 in YesWiki
Summary
by MITRE • 10/27/2026
YesWiki before 4.7.0 contains a read-ACL bypass in AclService::updateRequestWithACL, which interpolates usernames into SQL LIKE patterns without escaping the _ and % wildcards. Self-registered attackers can use usernames such as ___ or %%% that over-match ACL tokens, reading pages and Bazar entries restricted to other users or groups via the public Bazar listing API.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in YesWiki versions prior to 4.7.0 represents a critical security flaw rooted in improper input validation within the access control mechanism. Specifically, the issue resides in the AclService::updateRequestWithACL method, which is responsible for determining user permissions by querying the database using SQL LIKE patterns. The core technical failure occurs because usernames provided during authentication or registration are interpolated directly into these SQL queries without proper escaping of wildcard characters. In standard SQL syntax, the underscore character serves as a single-character placeholder and the percent sign acts as a multi-character placeholder within string matching operations. By failing to sanitize these specific inputs, the application allows attackers to manipulate the scope of database searches intended for access control verification.
This technical flaw enables self-registered attackers to bypass read-access controls through crafted usernames containing sequences such as underscores or percent signs. When an attacker registers with a username like _ or %%%, the resulting SQL query expands its search criteria far beyond the intended exact match. Instead of checking permissions solely for that specific user, the database returns results matching any string that fits the wildcard pattern. This effectively over-matches ACL tokens, causing the system to grant access privileges associated with other users or groups. Consequently, an attacker can exploit this logic error to read pages and Bazar entries that are strictly restricted to authorized individuals or private groups, thereby compromising the confidentiality of sensitive content stored within the wiki environment.
The operational impact of this vulnerability is significant as it undermines the fundamental principle of least privilege in a collaborative platform. Since YesWiki often hosts community-driven content where certain sections may contain confidential information, personal data, or proprietary documents, unauthorized access poses substantial risks. The exploitation via the public Bazar listing API further exacerbates the severity by allowing remote attackers to retrieve restricted entries without needing prior authenticated sessions for those specific resources. This exposure can lead to data leakage, intellectual property theft, and potential compliance violations depending on the nature of the stored information. It also erodes trust among users who expect their private contributions to remain secure from public view or unauthorized access by other registered members.
From a classification perspective, this vulnerability aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command (SQL Injection variant) and more specifically CWE-940 Improper Validation of Specified Input in SQL LIKE Patterns. It also maps to MITRE ATT&CK techniques related to Privilege Escalation via Access Control Misconfiguration, as the attacker leverages a flaw in permission logic to gain unauthorized access to restricted resources. To mitigate this risk, immediate patching to version 4.7.0 or later is required where the AclService has been updated to properly escape wildcard characters before interpolation into SQL queries. Additionally, developers should implement strict input validation that rejects usernames containing special SQL metacharacters if such usage is not functionally necessary for access control logic. Enforcing parameterized queries rather than string concatenation would provide a more robust defense against similar injection-based vulnerabilities in the future.