YesWiki EUVD-2026-110528

Requires YesWiki self-registration to be enabled, which is the default (noSignupButton=false); the attacker registers an account whose username is composed of LIKE metacharacters ('___' matches any ACL token of length >= 3; '%%%' reduces the predicate to LIKE "%", matching every ACL-protected row), which the UserController::PATTERN_USER_NAME validator accepts because it excludes neither _ nor %. Exploitation then requires calling the public Bazar entry-listing API (e.g. /?api/entries/bazarlist or /?api/forms/{formId}/entries/json) with filterOnReadACL in effect as a non-administrator. Limiting factors: exploitation yields confidentiality loss only of ACL-restricted Bazar/wiki content (no write or availability impact), depends on self-registration being enabled, and requires that Bazar entries with restrictive read ACLs actually exist to be exposed. Per-version note: at or below 4.6.6 the identity is not escaped at all, additionally permitting classic SQL breakout; the 5.0.0-alpha line uses parameterized LIKE ? ESCAPE and is not affected. Vendor interim mitigation is to disable the signup button and audit existing usernames for _ or % characters.

Signals point to a real but moderate-urgency confidentiality issue rather than a drop-everything emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H) yields 7.1 and reflects network-reachable, low-complexity exploitation requiring only a low-privileged account - and since self-registration is enabled by default (noSignupButton=false), that PR:L barrier is trivially met by any anonymous visitor. Impact is confidentiality-only (VC:H, VI:N, VA:N): no write or availability effect was demonstrated. Countervailing signals temper urgency: EPSS is 0.28% (20th percentile), there is no CISA KEV listing, and no active exploitation is reported - VulnCheck authored the advisory. A detailed public reproduction (register '___' or '%%%', hit the Bazar listing API) exists in the GHSA advisory, so exploitation is technically straightforward, but it is a PoC description, not packaged weaponized code. The vuln.today decision label is 'this_week', consistent with a serious access-control break that is not under active mass exploitation. One material conflict must be flagged: the input metadata and EUVD say this is fixed in 4.7.0, yet the referenced patch commit f3b0dd09 only modifies SearchManager numeric-filter handling (the fix for the separate CVE-2026-52770) and does not touch AclService where this flaw lives - verify the actual fix version with the vendor before treating 4.7.0 as remediated.

An attacker self-registers on a default YesWiki install with a username made of SQL LIKE wildcards (e.g. '___' or '%%%'), which the username validator accepts. Logging in and calling the public Bazar entry-listing API, the attacker's name is interpolated unescaped into the ACL predicate 'list LIKE "%<name>%"', causing it to over-match ACL tokens and return pages and Bazar entries restricted to other users or groups (including admin-restricted content). A public proof-of-concept with step-by-step reproduction exists in the GHSA advisory, though it is not verified as packaged working exploit code.