YesWiki EUVD-2026-91479

Exploitation requires that the YesWiki 'lost password' / password-reset feature has been used and that a resulting reset URL remains accessible to the attacker - the description explicitly names mailboxes, logs, backups, or browser history as the source of the token. Because YesWiki does not attach an expiry timestamp to these tokens, any previously issued, unused reset link stays valid indefinitely and can be replayed through checkEmailKey(). The key limiting factors are: the attacker must obtain a specific valid-but-unused reset URL out-of-band (reflected as AC:H and AT:P), a reset must have been initiated for the target account, and the YesWiki instance must be running a version before 4.6.7. No authentication (PR:N) or victim interaction (UI:N) is needed once the link is in hand.

This is a moderate, context-dependent risk rather than a drop-everything emergency. The provided CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N, base 6.3) tells a consistent story: although the attack is network-based and requires no authentication (PR:N) or victim interaction (UI:N), it carries both high complexity (AC:H) and a present attack requirement (AT:P) because the attacker must first obtain a valid-but-unused password reset URL from an out-of-band source (mailbox, log, backup, or browser history). That precondition is the dominant risk limiter - the flaw is not self-contained remote code execution but an exploitation of leaked/stale reset links. Exploitation status is 'no public exploit identified at time of analysis': there is no CISA KEV listing and no POC flagged in the input, so there is no evidence of active exploitation; it was reported by VulnCheck and a vendor advisory (GHSA) exists. No EPSS score was provided, so exploitation probability cannot be quantified from this data. The impact metrics are modest (VC:L/VI:L, no availability impact), which is arguably conservative given that successful exploitation yields full account takeover - if the targeted account is an administrator, real-world impact could be higher than the Low/Low rating suggests. Net: a legitimate issue worth patching promptly, but the AC:H/AT:P prerequisites make it opportunistic/targeted rather than mass-exploitable.

An attacker gains access to a stale password-reset email still sitting in a mailbox, server log, backup archive, or browser history - for example a departed employee's inbox or an exposed log file. Because the reset token has no expiry timestamp, the attacker replays the still-valid reset URL against checkEmailKey() and sets a new password, taking over the victim's YesWiki account. No public exploit code is identified, and the high attack complexity reflects the need to first acquire a valid unused reset link.