YesWiki EUVD-2026-91455

Requires an authenticated low-privilege YesWiki account (PR:L) and that the instance exposes the comments API editComment route (api/comments). The attacker must supply a victim page's identifier in the pagetag field; the route then overwrites content or reparents pages/comments without honoring per-page write ACLs. Exploitation is limited by the need for valid credentials, so instances with open/self-service registration or many low-trust users are most exposed, while instances restricting account creation substantially reduce the attacker population. No user interaction by a victim is required (UI:N).

This is a genuine but moderate-priority authorization-bypass flaw (CWE-639, IDOR-style user-controlled key) rather than a critical emergency. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) indicates network-reachable, low-complexity exploitation requiring an authenticated low-privilege account, with impact concentrated on integrity (VI:H) and partial availability (VA:L) and no confidentiality impact (VC:N) - consistent with an attacker overwriting/reparenting content but not reading protected data. Exploitation status: no public exploit identified at time of analysis (not listed in CISA KEV, no POC provided in the intelligence). No EPSS score was supplied, so statistical exploitation probability cannot be weighed. The signals are internally consistent - the PR:L requirement meaningfully limits the attacker population to those who can already obtain a low-privilege YesWiki account, which tempers the otherwise network-facing profile. The 7.1 rating reflects content-integrity damage to a self-hosted wiki, not remote code execution or data theft; priority should be driven by whether an organization runs internet-exposed YesWiki with open or low-barrier registration.

An attacker registers or obtains a low-privilege account on an internet-facing YesWiki instance, then sends a crafted POST to the api/comments editComment route specifying a victim page's tag in the pagetag field. Because the route fails to enforce per-page write ACLs against the supplied tag, the attacker overwrites protected page content or reparents existing pages/comments they should not be able to modify. No public exploit code is identified, but the attack is straightforward given an authenticated session.