YesWiki CVE-2026-116202

Exploitation requires: (1) a low-privilege authenticated account on the target YesWiki instance - the entries API endpoint POST /api/entries/{formId} is reachable by any authenticated user (acl '+'); (2) a target form that uses the bazar ImageField; and (3) the default attach_config.ext_images setting ('avif|gif|jpeg|png|jpg|svg|webp') which permits svg uploads out of the box, so default configurations of YesWiki before 4.7.0 are vulnerable with no special hardening removed. The ImageField gate is isImage() only, with no cleanFile()/sanitizer, so the uploaded SVG is stored unmodified and served as image/svg+xml. Limiting factors: the attacker must be authenticated (not anonymous), and script execution requires a victim to view the entry or navigate to the stored SVG URL (passive user interaction); affected versions are strictly before 4.7.0.

The signals converge on a moderate, not urgent, priority. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N, base 5.1) describes a network-reachable but low-privilege-authenticated stored XSS whose impact falls only on the subsequent system (the victim's browser/session: SC:L/SI:L), with no direct confidentiality, integrity or availability impact to the YesWiki server itself. This is consistent with a CWE-79 stored XSS rather than a server-compromise bug. Two limiting factors temper the network vector: an attacker must already hold a low-privilege authenticated account (PR:L), and a victim must view the entry or stored file for the script to fire (UI:P). No EPSS score was supplied, so exploitation probability cannot be quantified. The vulnerability is NOT in CISA KEV and there is no indication of active exploitation. A detailed public PoC reference exists in the GHSA advisory (reproduced on a live v4.6.7 instance by VulnCheck/the 'theo' agent, with screenshot and video evidence), but the input does not mark it as packaged, verified working exploit code. The vuln.today decision label is 'this_month', aligning with patch-on-normal-cycle urgency rather than emergency. Notably this is an incomplete fix for the prior advisory GHSA-67v5-7pfv-pp9m (CVE-2026-104461): the earlier remediation added cleanFile() only to FileField.php and skipped the sibling ImageField sink, so a patched-looking v4.6.7 remains exploitable. Overall this is a genuine, confirmed-reproducible but bounded-impact issue - a real priority for YesWiki operators to patch in the normal cycle, not a high-CVSS-but-low-real-risk false alarm nor a drop-everything emergency.

A low-privilege authenticated user POSTs a malicious SVG to /api/entries/{formId} through the bazar ImageField; the file is stored byte-identical and later served as image/svg+xml. When another user - or an admin - opens the entry or navigates directly to the stored file URL, the embedded script executes in the YesWiki origin, enabling session/cookie theft or actions as the viewer. A public PoC reference with reproduction steps and executed-alert evidence exists in the GHSA advisory; it is not confirmed as packaged, verified working exploit code.