YesWiki EUVD-2026-91471

Requires a YesWiki instance (before 4.6.7) that exposes a Bazar list which anonymous users can edit, so the attacker can insert a crafted option id that is later concatenated unescaped into SQL REGEXP/LIKE clauses in actions/newtextsearch.php. No authentication is required (PR:N) and no user interaction is needed. Limiting factors: the deployment must actually permit anonymous Bazar list editing (non-guaranteed configuration), and because the flaw is a blind boolean oracle, data extraction requires many requests and is slow and noisy rather than a single-shot dump.

Signals are moderately strong but not uniformly high. The authoritative CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N, VC:H) scores 8.7 and describes a fully network-reachable, unauthenticated path that discloses high-value data (admin password hashes from yeswiki_users), which is a genuine priority for any exposed instance. However, confidentiality is the only impact (VI:N/VA:N) - this is a read-only blind oracle, not code execution or data tampering. No EPSS score, no CISA KEV listing, and no confirmed public POC were provided, so there is no evidence of active or at-scale exploitation at this time; the finding originates from VulnCheck research rather than incident reporting. A material caveat the raw CVSS hides: exploitation depends on the presence of an anonymously editable Bazar list containing an attacker-controlled option id, a deployment-specific precondition not reflected in the AC:L/AT:N metrics. Net: a real, patch-now issue for internet-facing YesWiki sites that expose anonymously editable Bazar lists, but the absence of exploitation telemetry and the niche product footprint place it below mass-exploited enterprise bugs.

An anonymous attacker locates a YesWiki (pre-4.6.7) site with a publicly/anonymously editable Bazar list, edits a list option id to embed SQL REGEXP/LIKE syntax, then issues repeated {{newtextsearch}} queries whose true/false responses act as a boolean oracle. Over many requests they exfiltrate arbitrary database contents character by character, including admin password hashes. No public exploit code was identified in the provided data, but the technique is straightforward and well-documented by the VulnCheck advisory.