Summary
YesWiki before 4.6.7 contains an SQL injection vulnerability in the Bazar nuagetag action. An attacker who can write page content may manipulate the tags attribute to alter a database query, potentially exposing password hashes and other table data; on default installations, page writing may be available without authentication.
Affected context
The vulnerability occurs in YesWiki's Bazar nuagetag action when the tags attribute is incorporated into a raw SQL IN clause without adequate escaping or parameterization. It becomes risky where an attacker can create or edit pages containing the relevant tag syntax and where the application database account can read sensitive tables.
Exploit preconditions
- Attack surface: YesWiki page content processed by the Bazar
nuagetagaction - Required access: Page-write access; this may be unauthenticated on default installations
- Trigger point: Processing a page containing a crafted
nuagetagtags attribute - Why exploitation is possible: Unescaped tag content is concatenated into a SQL
INclause, allowing input to change query structure and introduce a UNION-based data retrieval operation
Why this happens
The underlying bug is the direct concatenation of untrusted input into a SQL statement. Because the tags attribute is not safely parameterized or otherwise constrained before being placed in the IN clause, attacker-controlled characters can disrupt the intended quoting and alter query semantics. This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL injection.
Potential impact
- An attacker may retrieve password hashes and other sensitive records
- Arbitrary table data could be disclosed
- Database integrity could be affected if additional query behavior is reachable
- Exposed credentials may enable unauthorized access to other systems
- The application and its users could experience privacy or confidentiality loss
General mitigation guidance
Mitigation generally focuses on removing string-built SQL queries from user-controlled data paths.
Common defensive patterns include:
- Use parameterized queries or prepared statements for all values, including dynamically handled lists
- Validate tags against an explicit allowlist and expected data type before database use
- Apply context-appropriate escaping only as a supplementary control, not as a replacement for parameterization
- Ensure database accounts follow least privilege and cannot read or modify unnecessary tables
- Restrict page-writing permissions and avoid anonymous content creation where it is not required
- Treat stored page content as untrusted input each time it is processed
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis rules identifying SQL strings built with concatenated or interpolated request and page-content values
- Code review checks for raw
INclauses assembled from user-controlled lists - Testing that submits quote, escape, delimiter, and malformed-list inputs to database-backed actions
- Web and database monitoring for unusual UNION terms, mismatched query errors, or unexpected reads across unrelated tables
- Policy enforcement requiring parameterized database APIs and least-privilege application credentials
- Automated security scanning and code-review tools configured to flag CWE-89 patterns
