CVE-2026-104456 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains a second-order SQL injection vulnerability in AclService::updateRequestWithACL, where a stored username is concatenated unescaped into a read-ACL LIKE clause. Attackers can self-register an account name containing a double-quote payload, then load non-admin ACL-filtered listings to read database contents and bypass read ACLs.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/02/2026
YesWiki versions prior to 4.6.7 are affected by a critical second-order SQL injection vulnerability located within the AclService::updateRequestWithACL method. This flaw stems from improper neutralization of special elements used in SQL commands, specifically involving the handling of user-supplied input during access control list updates. The root cause lies in the concatenation of a stored username directly into a read-Access Control List LIKE clause without proper escaping or parameterization. Because this is a second-order vulnerability, the malicious payload does not execute immediately upon entry but remains dormant within the database until it is retrieved and processed by the application logic during subsequent operations.
The exploitation vector begins with an attacker self-registering for an account using a username that contains a carefully crafted double-quote payload designed to break out of the SQL string context. Once this maliciously formatted username is stored in the database, it becomes part of the persistent data state. When an administrator or any user subsequently loads ACL-filtered listings, the application retrieves the stored username and concatenates it into the SQL query for filtering read access permissions. At this point, the unescaped double-quote allows the attacker to inject arbitrary SQL code that is executed by the database engine. This mechanism effectively bypasses the intended security controls because the injection occurs within a context where input validation was previously applied but not reapplied during execution.
The operational impact of this vulnerability is severe, as it grants attackers the ability to read sensitive contents from the underlying database beyond their authorized permissions. By manipulating the LIKE clause, an attacker can extract data that should be restricted by ACLs, potentially exposing user credentials, private wiki pages, or other confidential information stored within the YesWiki instance. This bypass of read access controls undermines the fundamental integrity and confidentiality guarantees provided by the application's security model. The ability to execute arbitrary SQL commands also opens the door for further exploitation techniques such as data exfiltration via error-based extraction or blind boolean-based inference attacks if direct output is not visible, although the primary impact described here focuses on unauthorized read access.
From a classification perspective, this vulnerability aligns with CWE-89 Improper Neutralization of Special Elements used in an SQL Command and specifically illustrates the dangers of second-order injection where input validation at entry points fails to account for later usage contexts. In terms of adversary tactics, this behavior corresponds to ATT&CK technique T1059 Command and Scripting Interpreter through SQL commands, allowing unauthorized access to data which falls under Data from Information Repositories in the Discovery phase or potentially Exfiltration Over Alternative Protocol if combined with other techniques. The failure lies not just in input validation but in the lack of consistent sanitization across all code paths that utilize user-supplied data for database queries.
To mitigate this vulnerability, immediate patching to version 4.6.7 or later is required as it addresses the underlying coding flaw by implementing proper parameterized queries or rigorous escaping mechanisms within the AclService::updateRequestWithACL method. Developers must ensure that all dynamic SQL construction uses prepared statements with bound parameters rather than string concatenation for user-supplied values. Additionally, input validation should be applied consistently at both entry and exit points of data processing pipelines to prevent stored payloads from being executed in subsequent operations. Security testing procedures should include second-order injection scenarios where inputs are stored and then triggered by different application functions to identify similar latent flaws before they can be exploited in production environments.