YesWiki EUVD-2026-110530

Exploitation requires: (1) a YesWiki instance (before 4.7.0) running the Bazar module with at least one form and one publicly readable entry (default read ACL is empty, which canRead() treats as public); (2) a target entry whose stored JSON lacks a specific text/title field key - this occurs when a field is added to a form after the entry was created, a normal wiki lifecycle state, not an unusual configuration; and (3) a victim who clicks the attacker's crafted link (UI:P/UI:R). The attacker names the query parameter after that missing field property (e.g., bf_custom) and supplies the payload. Limiting factors: success depends on the missing-field-key precondition and on user interaction, so it is not a zero-click default-config compromise; HttpOnly cookies prevent direct cookie theft (limiting impact to same-origin authenticated actions and content exfiltration); and no CSP is present to blunt inline script. There is no configuration-only workaround per the vendor - the code path must be patched.

Signals converge on a genuine but moderate-priority issue rather than an emergency. The CVSS 4.0 base is 5.3 (medium): network vector (AV:N), low complexity (AC:L), no privileges (PR:N), but passive user interaction required (UI:P) and only low vulnerable- and subsequent-system impact (VC/VI/SC/SI:L). EPSS is low at 0.18% (7th percentile), there is no CISA KEV listing, and the vuln.today decision label is 'this_month' - all consistent with a vulnerability that is exploitable but not under mass automated exploitation. A public PoC reference exists in the YesWiki GHSA advisory (GHSA-hcvp-q8fx-84mc), which raises exploitability above a purely theoretical finding; it is detailed step-by-step reproduction, not verified packaged exploit code. The low EPSS alongside a published PoC suggests opportunistic/targeted use rather than widespread exploitation, matching the niche deployment footprint of YesWiki. One data conflict must be verified: the aggregate metadata reports 'Patch: Available from vendor' and 'fixed in 4.7.0', but the GHSA advisory body itself states 'Fix status: not fixed' with latest checked release v4.6.7 - confirm the 4.7.0 fix with the vendor before treating the patch as released. Overall this is a real reflected XSS worth remediating this cycle, not a drop-everything event.

An unauthenticated attacker crafts a link to a public Bazar entry that is missing a form field key (a normal state when an admin adds a field to a form after entries already exist), appending a query parameter named after that field with a JavaScript payload. When an authenticated victim clicks the link, BazarField::getValue() falls back to the attacker-controlled $_REQUEST value and it is rendered through a Twig |raw template without escaping, executing script in the victim's session. A public PoC reference exists in the GHSA advisory demonstrating alert(document.domain); session cookies are HttpOnly, but the attacker can still perform same-origin authenticated actions and exfiltrate page content.