Summary
YesWiki contains a blind SQL injection vulnerability in the {{newtextsearch}} action. An anonymous attacker may be able to influence a Bazar option identifier and use search responses as a boolean oracle to infer arbitrary database contents, including administrator password hashes.
Affected context
The vulnerability occurs in YesWiki deployments using the {{newtextsearch}} action and anonymously editable Bazar lists. It becomes risky when Bazar list option identifiers are incorporated into SQL REGEXP or LIKE clauses without adequate escaping or parameterization, allowing attacker-controlled values to affect database queries.
Exploit preconditions
- Attack surface: The publicly accessible
{{newtextsearch}}search action - Required access: Anonymous access, together with the ability to add or influence an option identifier in an anonymously editable Bazar list
- Trigger point: A search request that processes the affected Bazar list option
- Why exploitation is possible: User-controlled option identifiers are concatenated into SQL pattern clauses, and response differences may reveal whether selected database conditions are true
Why this happens
The underlying bug is an SQL injection flaw caused by concatenating attacker-influenced Bazar option identifiers into database query expressions. Instead of treating the identifier as data with a fixed query structure, the application allows input to alter REGEXP or LIKE semantics. This maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command, and the blind nature of the issue means information can be inferred from observable query behavior without directly returning database records.
Potential impact
- An attacker may infer arbitrary database values through boolean-based responses
- Sensitive application data could be disclosed
- Administrator password hashes may be exposed
- Retrieved hashes could support offline password-cracking attempts
- Database confidentiality and application integrity could be compromised
General mitigation guidance
Mitigation generally focuses on preserving a fixed SQL query structure and reducing trust in user-controlled identifiers.
Common defensive patterns include:
- Use parameterized queries or equivalent safe database APIs for all dynamic values
- Apply context-aware escaping when values are used in SQL pattern expressions
- Validate Bazar option identifiers against a strict expected format and length
- Avoid anonymous editing of data that is later used in privileged search or query operations
- Enforce least-privilege database permissions and restrict access to sensitive tables
- Store password material using strong, modern password hashing and limit exposure of authentication data
How teams detect issues like this
Organizations can identify similar issues through:
- Static analysis rules that flag string concatenation or interpolation in SQL statements
- Code review checks for dynamic
REGEXP,LIKE, and other query clauses - Testing that submits unexpected metacharacters and observes response differences without relying on production data
- Database activity monitoring for unusual search patterns, repeated conditional requests, or access to authentication tables
- Policy enforcement requiring parameterized queries and approved database access layers
Automated security review tools may help identify unsafe query construction, but findings should be validated against the application's actual data flow and access controls.
