CVE-2026-104462 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains an SQL injection vulnerability in the Bazar nuagetag action, which concatenates the unescaped tags attribute into a raw SQL IN clause. Attackers with page-write access (unauthenticated on default installs) can embed a nuagetag tag ending in a backslash to break quote parity and inject a UNION subquery, exfiltrating password hashes and arbitrary table data.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
YesWiki versions prior to 4.6.7 are susceptible to a critical SQL injection vulnerability located within the Bazar nuagetag action module. This flaw arises from improper neutralization of special elements used in SQL commands, specifically where the application concatenates user-supplied input directly into a raw SQL IN clause without adequate sanitization or parameterization. The core technical deficiency lies in the handling of the tags attribute associated with the nuagetag tag. When processing this attribute, the software fails to escape single quotes or validate the structure of the input string before embedding it into the database query logic. This lack of proper input validation allows an attacker to manipulate the syntax of the SQL statement by introducing malicious characters that alter the intended execution path of the query.
The operational impact of this vulnerability is severe, particularly because the attack vector requires only page-write access, which in default installations is available to unauthenticated users. An adversary can exploit this weakness by embedding a nuagetag tag ending with a backslash character within a wiki page they have permission to edit or create. The presence of the trailing backslash serves to break quote parity, effectively escaping out of the current string context and allowing for the injection of arbitrary SQL code. By carefully crafting the injected payload, an attacker can append a UNION-based subquery to the original statement. This technique enables the extraction of sensitive data from the database backend that was not originally intended by the application logic.
Through this exploitation method, attackers are able to exfiltrate password hashes and access arbitrary table data stored within the YesWiki database. The retrieval of password hashes poses a significant risk as these can be subjected to offline brute-force or rainbow table attacks to recover plaintext credentials for user accounts. Furthermore, accessing arbitrary table data may reveal configuration details, personal information, or other sensitive content depending on the schema design and data retention policies of the specific deployment. This level of access effectively compromises the confidentiality and integrity of the entire application environment, potentially leading to full system compromise if combined with other vulnerabilities such as remote code execution via uploaded files containing these credentials.
From a classification perspective, this vulnerability aligns with CWE-89 Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. The exploitation technique described, which involves manipulating the structure of the query to extract data from unrelated tables using UNION statements, is characteristic of techniques found under MITRE ATT&CK ID T1059 Sub-Commands or more specifically T1142 SQL Query Modification if considering the broader context of database interaction manipulation. However, the specific act of extracting data via UNION SELECT falls squarely within standard SQL injection exploitation patterns documented in various security frameworks as a primary method for data exfiltration from relational databases.
To mitigate this vulnerability, administrators and developers must upgrade to YesWiki version 4.6.7 or later where the issue has been addressed through improved input validation and query parameterization. In environments where immediate patching is not feasible, temporary mitigations should include restricting page-write permissions to authenticated users with elevated privileges rather than default unauthenticated access. Additionally, implementing a Web Application Firewall (WAF) with rules tuned to detect SQL injection patterns in URL parameters or POST data can provide an additional layer of defense by blocking malicious payloads before they reach the application logic. Regular security audits and code reviews focusing on database interaction points are also recommended to prevent similar issues from arising in future development cycles.