CVE-2026-116207 in YesWiki
Summary
by MITRE • 10/25/2026
YesWiki 4.6.0 before 4.7.0 and 5.0.0-alpha1 before 5.0.0-alpha4 contains an unauthenticated SQL injection vulnerability in SearchManager::prepareSearchRequest(). Field names from the query and searchfields parameters of the public Bazar entries search API are placed in a backtick-quoted alias escaped only with mysqli_real_escape_string. Attackers can supply a backtick to inject subqueries, reading data such as user password hashes or exhausting database threads with SLEEP().
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/25/2026
YesWiki versions 4.6.0 through 4.7.0 and the alpha releases from 5.0.0-alpha1 up to but not including 5.0.0-alpha4 are affected by a critical unauthenticated SQL injection vulnerability located within the SearchManager::prepareSearchRequest() method. This flaw specifically impacts the public Bazar entries search API, which is designed to allow users to query and retrieve data from the application's database without requiring prior authentication. The security failure stems from an insufficient sanitization mechanism applied to user-supplied input fields, particularly those passed via the field names in the query parameter as well as the searchfields parameters. These inputs are intended to specify which columns or attributes of the Bazar entries should be searched and returned by the API endpoint.
The technical root cause lies in how these specific input values are processed before being incorporated into SQL statements. The application attempts to mitigate injection risks by wrapping field names in backticks, a common practice for escaping identifiers in MySQL-based systems. However, the sanitization function used is mysqli_real_escape_string, which is primarily designed to escape special characters within string literals rather than identifier names like column or table names. This mismatch creates a significant security gap because mysqli_real_escape_string does not adequately neutralize backticks themselves when they are part of an identifier context that is already wrapped in backticks. Consequently, if an attacker supplies a value containing a closing backtick followed by malicious SQL syntax and then re-opens the quote with another backtick, they can effectively break out of the intended identifier scope.
This architectural flaw allows unauthenticated attackers to inject arbitrary subqueries into the database execution context. By carefully crafting payloads that exploit the improper escaping of field names, an attacker can manipulate the structure of the SQL query executed by the backend. The operational impact is severe because it grants unauthorized access to sensitive data stored within the YesWiki database. Attackers can extract confidential information such as user password hashes, personal details associated with Bazar entries, and other proprietary content that should remain inaccessible without proper administrative privileges. This represents a classic case of CWE-89 Improper Neutralization of Special Elements used in an SQL Command allowing for data exfiltration from the underlying database system.
Beyond direct data theft, this vulnerability also enables denial-of-service attacks through time-based injection techniques. An attacker can inject commands that utilize functions such as SLEEP() to deliberately delay query execution. By doing so, they can exhaust available database threads and connections, leading to service degradation or complete unavailability for legitimate users. This capability aligns with ATT&CK technique T1496 Resource Hijacking where resources are consumed to disrupt availability. The combination of data exfiltration potential and resource exhaustion makes this vulnerability particularly dangerous in production environments where the Bazar API is exposed to external traffic without additional protective layers such as Web Application Firewalls that might detect or block malformed SQL patterns before they reach the application logic.
To mitigate this risk, immediate action must be taken by upgrading YesWiki to version 5.0.0-alpha4 or later, where the issue in SearchManager::prepareSearchRequest() has been addressed with more robust input validation and proper identifier escaping mechanisms that align with database-specific requirements for handling column names. For organizations unable to upgrade immediately due to compatibility constraints, implementing a Web Application Firewall rule set capable of detecting SQL injection patterns within query parameters can provide temporary protection. Additionally, restricting access to the Bazar entries search API by requiring authentication or limiting it to trusted IP ranges reduces the attack surface available to unauthenticated adversaries. It is also recommended to review database user permissions to ensure that the account used by the web application operates with minimal privileges, thereby limiting the potential damage even if an injection succeeds.