CVE-2026-104460 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains a blind SQL injection vulnerability in the {{newtextsearch}} action because Bazar list option ids are concatenated into SQL REGEXP/LIKE clauses in actions/newtextsearch.php without escaping. Anonymous attackers can plant a malicious option id in an anonymously editable Bazar list and use search requests as a boolean oracle to read arbitrary database data, including admin password hashes from the yeswiki_users table.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in YesWiki versions prior to 4.6.7 represents a critical blind SQL injection flaw located within the newtextsearch action of the Bazar module. This security defect arises from improper input validation and sanitization practices, specifically regarding how user-supplied data is handled during database query construction. The core technical issue stems from the concatenation of list option identifiers directly into SQL REGEXP or LIKE clauses without any form of escaping or parameterized query preparation. In a typical web application architecture, inputs such as search terms or filter options are expected to be treated strictly as data values rather than executable code components. However, in this implementation, the system treats these input strings as part of the SQL syntax itself, creating an injection point that allows attackers to manipulate the structure and intent of database queries.
From a technical perspective, the vulnerability exploits the lack of proper escaping mechanisms for special characters within the Bazar list option IDs. When a user submits a search request containing a maliciously crafted option ID, the application incorporates this input directly into the SQL statement used to filter results. Because the input is not sanitized against SQL metacharacters such as single quotes or logical operators like OR and AND, an attacker can close the intended string context and inject arbitrary SQL commands. The nature of this injection is classified as blind because it does not return data directly in the HTTP response body. Instead, attackers must rely on boolean-based inference techniques to extract information. By carefully crafting payloads that trigger different application behaviors or timing delays based on true or false conditions within the injected query, an attacker can systematically deduce database contents bit by bit.
The operational impact of this vulnerability is severe due to its potential for unauthorized data access and privilege escalation. Since the injection point exists in a context accessible via search requests, it may be reachable without authentication if the specific Bazar list allows anonymous editing or searching capabilities. This accessibility profile enables unauthenticated attackers to interact with the database engine directly. The most significant consequence is the ability to read arbitrary data from the backend MySQL database. Attackers can leverage this access to extract sensitive information such as administrative password hashes stored in the yeswiki_users table. Compromising these credentials allows for full account takeover, granting the attacker administrator-level privileges over the YesWiki instance and enabling further exploitation of other system features or integration points.
This vulnerability aligns with CWE-89, which describes Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. The specific technique employed by attackers falls under ATT&CK tactic T1059, specifically subtechnique T1059.004 for Command and Scripting Interpreter interactions via database queries, although the primary classification remains within data exfiltration methods associated with blind injection vectors. The exploitation relies on boolean-based oracle techniques where the application's response serves as a binary indicator of query success or failure, allowing precise reconstruction of hidden data fields without direct output display.
Mitigation strategies must focus on implementing secure coding practices that prevent SQL code from being constructed through string concatenation of user inputs. The primary remediation involves replacing dynamic query construction with parameterized queries or prepared statements provided by the database abstraction layer used in YesWiki development. This ensures that input data is always treated as literal values rather than executable syntax, effectively neutralizing injection attempts regardless of their content. Additionally, implementing strict input validation and whitelisting for Bazar list option IDs can provide an additional layer of defense by rejecting any characters or patterns not explicitly allowed by the application logic. Upgrading to YesWiki version 4.6.7 or later is essential as these versions contain patches addressing this specific flaw in the newtextsearch action, ensuring that proper escaping and sanitization routines are applied before data reaches the database engine.