high · 7.5CVE-2026-52770Jul 9, 2026

CVE-2026-52770: YesWiki Bazar API Unauthenticated Boolean-Based SQL Injection

Shubham Kandhare
Security Engagement Manager, SecureLayer7

Any unauthenticated visitor can inject SQL into YesWiki's public Bazar entry-listing API by abusing numeric field filters, turning the API into a boolean oracle that leaks database contents including

Packageyeswiki/yeswiki
Ecosystemcomposer
Affected< 4.6.6
Fixed in4.6.6

The problem

YesWiki's public Bazar API accepts `query` and `queries` GET parameters on several unauthenticated routes (`/api/forms/{formId}/entries/...`, `/api/entries/...`, `/api/entries/bazarlist`). These filters are parsed and passed into `SearchManager::buildQueriesConditions()`.

When a field is typed as `number`, the code escapes the attacker-supplied value with `mysqli_real_escape_string` but inserts it unquoted directly into the SQL predicate: `CAST(... AS DOUBLE) > <value>`. Escaping alone does not neutralise SQL syntax in an unquoted numeric context, so an attacker can append boolean subqueries.

No authentication is required.

Proof of concept

A working proof-of-concept for CVE-2026-52770 in yeswiki/yeswiki, with the exact payload below.

http
GET /api/entries/bazarlist?formId=1&queries=bf_age>100 OR (SELECT COUNT(*) FROM yeswiki_users)>0 HTTP/1.1
Host: target.example.com

The root cause is that `buildQueriesConditions()` in `tools/bazar/services/SearchManager.php` applies `mysqli_real_escape_string` but never wraps the value in quotes or validates that it is a bare number. The resulting fragment is `CAST(bf_age AS DOUBLE) > 100 OR (SELECT COUNT(*) FROM yeswiki_users)>0`, which the database evaluates before any PHP-level ACL or BazarGuard post-processing runs.

This makes it a classic unquoted numeric injection (CWE-89). An attacker observes whether entries are returned (true subquery) or not (false subquery) to extract data one bit or character at a time from any table the DB user can read, including `yeswiki_users` with password hashes.

The fix in commit `f3b0dd093a7ace47dc29a515faeb02635baceae2` adds strict numeric validation, ensuring the value is cast or matched against a real number pattern before being interpolated into the query.

The fix

Upgrade to YesWiki 4.6.6 or later. The patch in commit f3b0dd093a7ace47dc29a515faeb02635baceae2 adds proper numeric validation in `SearchManager::buildQueriesConditions()` so that only a literal number can be interpolated into the unquoted position, eliminating the injection point.

No workaround short of blocking public access to the Bazar API routes is effective on earlier versions.

Reporter not attributed.

References: [1][2][3]

Related research