Summary
YesWiki contains an unauthenticated SQL injection vulnerability in the public Bazar entries search API. An attacker may manipulate search-related field parameters to alter database queries, disclose sensitive records such as password hashes, or consume database resources when the vulnerable search path is reachable.
YesWiki contains an unauthenticated SQL injection vulnerability in the public Bazar entries search API. An attacker may manipulate search-related field parameters to alter database queries, disclose sensitive records such as password hashes, or consume database resources when the vulnerable search path is reachable.
Affected context
The issue occurs in YesWiki deployments using the affected Bazar entries search functionality. Field names derived from the query and searchfields parameters are incorporated into backtick-quoted SQL aliases with escaping that does not safely constrain SQL syntax, creating risk when the public search API accepts attacker-controlled input.
The issue occurs in YesWiki deployments using the affected Bazar entries search functionality. Field names derived from the query and searchfields parameters are incorporated into backtick-quoted SQL aliases with escaping that does not safely constrain SQL syntax, creating risk when the public search API accepts attacker-controlled input.
Exploit preconditions
- Attack surface: Public Bazar entries search API
- Required access: No authentication may be required when the endpoint is exposed
- Trigger point: Processing of attacker-controlled
queryorsearchfieldsparameters bySearchManager::prepareSearchRequest() - Why exploitation is possible: User-supplied field names are inserted into SQL query construction without context-appropriate identifier handling, allowing database expressions to influence query behavior
- Attack surface: Public Bazar entries search API
- Required access: No authentication may be required when the endpoint is exposed
- Trigger point: Processing of attacker-controlled
queryorsearchfieldsparameters bySearchManager::prepareSearchRequest() - Why exploitation is possible: User-supplied field names are inserted into SQL query construction without context-appropriate identifier handling, allowing database expressions to influence query behavior
Why this happens
The vulnerability results from treating attacker-controlled field names as safely escaped SQL identifiers when constructing a database query. Applying string escaping designed for values does not reliably protect identifier or expression contexts, particularly when delimiter characters remain meaningful to the SQL parser. This insecure query-construction pattern maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').
The vulnerability results from treating attacker-controlled field names as safely escaped SQL identifiers when constructing a database query. Applying string escaping designed for values does not reliably protect identifier or expression contexts, particularly when delimiter characters remain meaningful to the SQL parser. This insecure query-construction pattern maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').
Potential impact
- Sensitive database records, including user password hashes, may be disclosed
- Unauthorized SQL expressions may alter the behavior of search queries
- Database threads and other resources could be exhausted
- The application may experience degraded availability or denial of service
- Exposed database information could support follow-on attacks
- Sensitive database records, including user password hashes, may be disclosed
- Unauthorized SQL expressions may alter the behavior of search queries
- Database threads and other resources could be exhausted
- The application may experience degraded availability or denial of service
- Exposed database information could support follow-on attacks
General mitigation guidance
Mitigation generally focuses on ensuring that user input cannot define SQL identifiers or expressions.
Common defensive patterns include:
- Restricting searchable fields to a server-side allowlist of known identifiers
- Separating validated identifiers from user-supplied query values
- Using parameterized queries for data values and safe query-builder abstractions where applicable
- Rejecting unexpected delimiters, operators, and structural input before query construction
- Applying least-privilege permissions to the database account used by YesWiki
- Limiting database exposure and adding resource controls to reduce query-based exhaustion
Mitigation generally focuses on ensuring that user input cannot define SQL identifiers or expressions.
Common defensive patterns include:
- Restricting searchable fields to a server-side allowlist of known identifiers
- Separating validated identifiers from user-supplied query values
- Using parameterized queries for data values and safe query-builder abstractions where applicable
- Rejecting unexpected delimiters, operators, and structural input before query construction
- Applying least-privilege permissions to the database account used by YesWiki
- Limiting database exposure and adding resource controls to reduce query-based exhaustion
How teams detect issues like this
Organizations can look for this issue through:
- Static analysis rules identifying string concatenation or interpolation in SQL construction
- Code review checks for user-controlled identifiers, aliases, and clauses
- Tests that exercise public search parameters with unexpected structural characters
- Web application firewall or API policy rules monitoring anomalous search requests
- Database logging and monitoring for unusual query shapes, metadata access, or long-running sleep-like behavior
Automated security review tools may help identify unsafe query-building patterns, but findings should be validated against the database abstraction and input-validation logic.
Organizations can look for this issue through:
- Static analysis rules identifying string concatenation or interpolation in SQL construction
- Code review checks for user-controlled identifiers, aliases, and clauses
- Tests that exercise public search parameters with unexpected structural characters
- Web application firewall or API policy rules monitoring anomalous search requests
- Database logging and monitoring for unusual query shapes, metadata access, or long-running sleep-like behavior
Automated security review tools may help identify unsafe query-building patterns, but findings should be validated against the database abstraction and input-validation logic.
