Description

YesWiki is a wiki system written in PHP. Prior to version 4.6.6, YesWiki’s public Bazar entry-listing APIs are vulnerable to unauthenticated SQL injection in numeric query / queries filters. For Bazar fields whose value structure is numeric, YesWiki escapes the attacker-controlled filter value but inserts it into SQL without quotes or numeric validation. An unauthenticated attacker can inject boolean SQL expressions and infer database contents from whether entries are returned. This issue has been patched in version 4.6.6.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-05T00:17:19.827Z",
  "pubdate": "2026-09-05T00:17:19.827Z",
  "executiveSummary": "YesWiki versions prior to 4.6.6 contain an unauthenticated SQL injection vulnerability within its public Bazar entry-listing APIs.\nThe vulnerability resides in the handling of numeric query and filter parameters, which fail to undergo rigorous validation before being concatenated into SQL statements.\nThis flaw allows remote, unauthenticated attackers to execute boolean-based blind SQL injection attacks against the backend database.\nBy injecting malicious SQL expressions, an adversary can infer sensitive information from the database contents by observing variations in API response outputs.\nSuccessful exploitation poses a significant risk to data confidentiality, as attackers can systematically extract data without requiring prior authentication or administrative privileges.\nThe vulnerability is limited to specific Bazar fields where the expected value structure is numeric, but the lack of server-side casting or validation creates a critical exposure point.\nOrganizations using affected versions are at risk of data exfiltration and unauthorized database interrogation and are encouraged to update to version 4.6.6 immediately.",
  "technicalDetails": "The vulnerability exists within the YesWiki Bazar component's entry-listing API, specifically affecting how the application processes filters for fields defined with a numeric structure.\nThe root cause is a failure in input sanitization logic where the application assumes that escaping the input is sufficient, even though the resulting value is inserted directly into the SQL query string without enclosing quotes or strict type validation.\nIn standard SQL constructions, numeric fields are often concatenated into the query without string delimiters. While the application attempts to escape the input, it neglects to verify if the input remains strictly numeric, allowing an attacker to break out of the intended numeric context.\nAn attacker can exploit this by passing boolean SQL expressions (e.g., OR 1=1, OR (SELECT 1 FROM users WHERE username='admin')=1) into the vulnerable filter parameters. Because the database engine evaluates these injected expressions as part of the WHERE clause, the API's behavior—either returning an entry list or an empty set—acts as a side channel.\nThe attack flow follows a boolean-based blind SQL injection methodology: 1. The attacker identifies a target API endpoint for Bazar entries. 2. The attacker crafts an HTTP request containing a malicious payload in the numeric filter parameter. 3. The server processes the query and includes the payload in the SQL statement executed against the backend database. 4. The attacker observes the response content length or entry count to confirm the truth value of the injected boolean condition. 5. Through iterative requests (often automated), the attacker can map out database schema, table contents, and record values.\nThis vulnerability is accessible over the network to any unauthenticated user capable of reaching the public-facing Bazar API endpoints. Since the vulnerability resides in the processing of GET or POST parameters by the application server, no specific session tokens or administrative privileges are required.\nThe lack of strong typing in the application layer means the database receives attacker-controlled input that the engine interprets as executable logic rather than literal data. Post-exploitation impact includes unauthorized access to all data accessible by the database user account, which may encompass user credentials, site content, and system configuration data."
}