YesWiki EUVD-2026-91480

Exploitation requires that the attacker can set or learn the victim's pre-authentication YesWiki-* session cookie (e.g., via a shared/public machine, a session-fixing link, or an auxiliary XSS/injection vector) AND that the targeted victim subsequently completes an authenticated login on the YesWiki instance - because AuthController login logic does not regenerate the PHP session ID. Limiting factors: success is gated on victim interaction (the login) and on the attacker first establishing cookie control, which is why CVSS marks AC:H and AT:P; it affects all YesWiki versions before 4.6.7, and upgrading to 4.6.7 (which regenerates the session ID on login) eliminates the condition.

This is a genuine but conditional risk rather than a drop-everything priority. The vendor-supplied CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:P) scores 7.6 (High), but the high attack complexity (AC:H), the present attack requirement (AT:P), and the required victim interaction (UI:P) materially temper real-world exploitability: the attacker must first set or learn the victim's pre-authentication YesWiki-* cookie and then wait for that specific victim to authenticate. No EPSS score, no CISA KEV listing, and no public exploit code are present in the provided data, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The combination of a chained precondition (cookie planting/learning) plus the session-fixation class (CWE-384) points to targeted, opportunistic abuse rather than mass automated exploitation. Note a tension worth verifying: PR:N labels this unauthenticated, yet successful impact depends entirely on a legitimate user completing login, so the practical attacker burden is higher than PR:N alone suggests.

An attacker plants a known YesWiki-* session cookie in a victim's browser (for example via an XSS sink, a shared/kiosk machine, or a crafted link) and then waits for the victim to log in to the YesWiki instance. Because login does not regenerate the PHP session ID, the fixed cookie becomes an authenticated session, letting the attacker reuse it to read private content and act with the victim's privileges. No public exploit code is identified at time of analysis, but the technique is well-understood and low-skill once cookie delivery is solved.