YesWiki EUVD-2026-91472

Exploitation requires an authenticated account with permission to submit Bazar entries that include a FileField upload, because the flaw is in the Bazar FileField handler which validates only the file extension and never invokes HtmlPurifierService::cleanFile. The attacker must craft an SVG containing script; successful compromise further requires a victim (typically an administrator) to open/view the stored SVG, which is served inline as image/svg+xml in the wiki origin - the attacker cannot self-trigger execution, matching UI:P in the CVSS vector. This user-interaction dependency and the authenticated-submission prerequisite (PR:L) are the main limiting factors; affects YesWiki versions before 4.6.7.

This is a genuine but moderate-priority issue, consistent with its 5.1 (Medium) CVSS 4.0 score rather than an urgent emergency. The vendor-provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P) shows network-reachable, low-complexity exploitation, but two factors dampen real-world risk: it requires an authenticated user (PR:L) able to submit Bazar entries, and it requires a victim to actually open the malicious SVG (UI:P / Passive). The impact metrics are limited - the vulnerable system itself sees no direct impact (VC:N/VI:N/VA:N) while a scope change to the subsequent system carries low confidentiality and integrity impact (SC:L/SI:L), reflecting that the payload executes in a victim's browser session rather than compromising the server directly. No EPSS score was provided in the input, and the CVE is not listed in CISA KEV; there is no public exploit identified at time of analysis. The signals are internally consistent - a classic stored-XSS risk profile where the primary danger is privilege escalation via an administrator opening attacker-supplied content, not mass unauthenticated takeover.

An attacker with a low-privileged authenticated YesWiki account submits a Bazar entry via POST /api/entries/{formId}, attaching an SVG file whose extension passes validation but whose embedded script is never sanitized. When an administrator later opens that SVG, it is served inline as image/svg+xml and the script executes in the wiki origin, allowing session or account compromise. No public exploit was identified at time of analysis.