YesWiki EUVD-2026-91456

Exploitation requires the target YesWiki instance (version before 4.6.7) to have the ActivityPub federation feature active and to host at least one mirrored/federated entry with a sourceUrl the attacker can reference; the flaw lives specifically in the ActivityPub inbox's failure to bind the verified HTTP signature signer to the activity actor. No authentication, credentials, or account on the target are needed (PR:N) - the attacker only needs to generate their own ActivityPub keypair - and no user interaction is required (UI:N). The principal limiting factor is deployment configuration: instances that have not enabled ActivityPub federation, or that mirror no remote entries, are not exposed. Impact is confined to deleting or overwriting other actors' federated entries, not reading data or compromising the host.

This is a credible, actionable priority for any YesWiki instance running ActivityPub federation, though its blast radius is bounded. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) indicates fully remote, unauthenticated, low-complexity exploitation with no user interaction - the worst-case access profile. The impact is integrity-focused (VI:H) with limited availability impact (VA:L) and no confidentiality loss (VC:N), consistent with a spoofing flaw (CWE-290) that lets an attacker delete or overwrite federated entries but not read data. No EPSS score, KEV listing, or POC was provided in the input, so there is no public exploit identified at time of analysis and no confirmed active exploitation; the apparent severity rests on the CVSS vector and the clarity of the advisory rather than on observed in-the-wild activity. The signals are internally consistent (network vector in CVSS matches the ActivityPub inbox described in the text), so there is no conflict to flag, but note the real-world exposure is gated by whether federation is actually enabled - see exploitation_conditions. Treat as a high-priority patch for federated deployments and a low/no-risk issue for instances that have not enabled ActivityPub.

An attacker generates any ActivityPub keypair (no prior account or authorization on the target), then sends a signed Delete or Update activity to a vulnerable YesWiki instance's inbox referencing the sourceUrl of an entry mirrored from a legitimate remote actor. Because the inbox verifies the HTTP signature but never checks that the signer matches the activity's claimed actor, the server accepts the forged activity and deletes or overwrites the victim actor's federated entry. No public proof-of-concept was provided in the input.