YesWiki CVE-2026-116206

Exploitation requires: (1) an authenticated account with comment access to the target page (PR:L - any registered user, ACL '+'); (2) allow_raw_html = true, which is the shipped default (includes/YesWikiInit.php:234); (3) comments_activated = true, also default; and critically (4) comments actually enabled on at least one reachable page - the global default_comment_acl is comments-closed, so an admin or page owner must have explicitly enabled comments, meaning default fresh installs are NOT exploitable until this common, documented configuration is applied. Once a comment-enabled page exists, the chain is deterministic with no further attacker steps. Execution needs a victim (visitor or admin) to view the page, but no victim click beyond viewing. Primary limiting factors: the comment-enablement precondition narrows the exploitable target population, authentication is required, and impact is constrained to script in the wiki origin (no script-src CSP directive is set, so inline/event-handler script is unrestricted). Interim mitigation per the advisory: set allow_raw_html to false (routes "".."" through htmlspecialchars but disables legitimate raw-HTML in page content); restricting comments reduces exposure but does not fix root cause.

This is a moderate-severity, authenticated stored XSS (CWE-79) in YesWiki, and the signals point to a real-but-bounded issue rather than a top-tier emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms a network-reachable, low-complexity attack by an authenticated low-privilege user (PR:L) with no attacker-side user interaction required; impact is capped at Low across confidentiality and integrity for both the vulnerable and subsequent systems (VC:L/VI:L/SC:L/SI:L), consistent with cookie/session theft and script execution rather than direct full compromise, hence the 5.3 base. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with the moderate score. No EPSS score and no CISA KEV entry were provided, so there is no evidence of active exploitation; absence of these is not itself a finding. A detailed public PoC reference exists in the GHSA advisory (exact /api/comments request and payload), so exploitation is well-understood and low-effort for anyone with a comment-capable account, but it is not verified as weaponized/working exploit code and must not be conflated with active exploitation. The most important nuance limiting real-world risk is a deployment precondition: comments must be enabled on a target page (global default_comment_acl is comments-closed), so default fresh installs are not exploitable until an operator enables comments - a documented, common, but non-automatic configuration. Net: a credible priority to patch on a normal cycle, elevated for any YesWiki instance that already has comments enabled on reachable pages, but not a drop-everything issue absent KEV/EPSS signals.

A registered low-privilege user posts a comment on a comment-enabled page via POST /api/comments, wrapping an image/onerror JavaScript payload in the wiki "".."" raw-HTML syntax. Because allow_raw_html is true by default and the comment template renders the body through Twig's |raw filter, the script is stored and then executes automatically in the browser of every subsequent viewer - including administrators - with no further interaction, enabling session-cookie theft. A full public PoC reference exists in the vendor GHSA advisory, though it is not verified as a packaged working exploit.