YesWiki EUVD-2026-91448

Exploitation requires that the target YesWiki instance (version < 4.6.7) expose the tags tool's listpagestag or includepages actions where an attacker can supply or embed them, and that read-ACL-restricted pages exist whose names/titles are worth disclosing. Per CVSS PR:N/UI:N/AC:L, no authentication, no user interaction, and no special non-default configuration are required - the actions fail to apply read-ACL filtering by design in affected versions, so default installations are affected. The principal LIMITING factors are impact scope rather than access: only page names and body-derived titles leak (not full page bodies), and the instance must actually host ACL-restricted pages for the disclosure to be meaningful.

This is a missing-authorization information-disclosure flaw (CWE-862) in YesWiki before 4.6.7. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) is self-consistent with the description: remote, unauthenticated, low-complexity exploitation with no user interaction, which legitimately warrants a high base score and the vendor's 8.7. However, the real-world impact is narrower than the 8.7 and the vendor's VC:H imply: the vulnerability leaks only page NAMES and body-derived TITLES of ACL-restricted pages, not their full contents, so confidentiality impact is partial rather than total (I assess C:L, see assessed vectors). There is NO integrity or availability impact (VI:N/VA:N). On exploitation signals, EPSS is not provided, the CVE is NOT in CISA KEV, and no public POC is referenced - so there is no public exploit identified at time of analysis and no evidence of active exploitation. Net: trivially exploitable and worth patching promptly because exploitation prerequisites are minimal, but the practical severity is metadata/recon-grade disclosure, not full data compromise - the 8.7 overstates business impact for most deployments.

An unauthenticated attacker who can reach any editable or renderable YesWiki page embeds the listpagestag or includepages action referencing a chosen tag or page name. Because the actions enumerate pages without applying read-ACL filtering, the response reveals the names and body-derived titles of pages the attacker should not be able to see, letting them map hidden/restricted content. No public exploit code is referenced, but the attack requires only a crafted action embed and no authentication.