Summary
YesWiki contains an SQL injection flaw in the Bazar filtertags action because filter tokens can reach a raw SQL IN clause without adequate escaping. On affected default installations, an unauthenticated attacker who can save crafted filtertags markup may read arbitrary database contents, including password hashes.
Affected context
The vulnerability occurs in YesWiki installations using the Bazar filtertags action, where filterN attribute values are incorporated into a tags.value IN clause. Risk is higher when unauthenticated users can create or edit pages containing filtertags markup and the application uses MySQL-compatible backslash escaping behavior.
Exploit preconditions
- Attack surface: The Bazar filtertags action and its page-markup processing
path.
- Required access: On default configurations, unauthenticated access may be
sufficient if page creation or editing permits the relevant markup.
- Trigger point: Server-side processing of filtertags attributes when the
generated database query is executed.
- Why exploitation is possible: Unescaped attribute tokens are quoted and
concatenated into a raw SQL IN expression, allowing input to alter query
structure and combine results with another query.
Why this happens
The underlying bug is a failure to separate SQL code from user-controlled values. The application constructs a database query by concatenating insufficiently escaped filterN tokens into a quoted IN clause; database parsing and backslash-escape behavior can then change quote boundaries and interpret attacker-controlled content as SQL. This is CWE-89, Improper Neutralization of Special Elements used in an SQL Command.
Potential impact
- An attacker may read arbitrary database records.
- Password hashes and other authentication-related data could be disclosed.
- Sensitive application, user, or configuration data could be exposed.
- Query results could be manipulated or combined with attacker-selected data.
- Further compromise could become possible if exposed data enables account takeover.
General mitigation guidance
Mitigation generally centers on eliminating SQL construction through string concatenation and reducing trust in page markup and filter attributes. Common defensive patterns include parameterized queries with safely bound values, allowlisted filter syntax, strict validation of expected token formats, and query-builder interfaces that preserve parameter separation. Access to page creation and editing can be restricted to trusted roles, while database accounts should use least privilege and sensitive values should be protected through appropriate hashing and secret-management practices.
How teams detect issues like this
Detection can include static analysis for SQL strings built with concatenated request, markup, or attribute values; code review checks for raw IN clauses assembled from user input; and tests that exercise quote, escape, delimiter, and malformed-token handling. Runtime monitoring may look for unusual filter expressions, database errors, unexpected UNION-like query patterns, and abnormal reads of authentication tables. CI policy enforcement and automated code-review tools can flag unparameterized database APIs and missing input validation.
