YesWiki CVE-2026-116208

Exploitation requires a specific non-default deployment: ActivityPub must be enabled on at least one Bazar form AND the instance must already hold at least one entry mirrored from a third-party federated actor. The attacker must operate (or control a compromised) remote ActivityPub server that the admin syncs with, and a YesWiki administrator must initiate the sync via ?vue=abonnements&action=sync&idformulaire={id}&actor={uri} - or be lured into triggering it, since the sync uses GET with no CSRF token. Limiting factors: admin-level interaction is required (UI:P), the ActivityPub/Bazar federation feature must be configured, and the attacker gains no standing privileges on the target. The attacker needs zero privileges on the YesWiki instance itself.

This is a genuine but conditional priority, not an inflated high-CVSS score. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:H, score 7.2) accurately captures a network-reachable flaw requiring no attacker privileges but requiring passive user interaction (UI:P) - a classic confused-deputy pattern where the YesWiki admin, not the attacker, performs the destructive action by initiating a sync. Integrity and availability impact are HIGH (forge/overwrite entries and mass-delete via garbage collection) while confidentiality is NONE, consistent with CWE-862 missing authorization. The vuln.today decision label is this_week, indicating elevated but not emergency urgency. KEV status is NOT present (no confirmed active exploitation) and no EPSS score was supplied, so exploitation probability cannot be quantified from the input. A detailed public PoC reference exists in the GHSA advisory (concrete malicious actor/outbox JSON and the exact sync URL), but the input does not confirm it as weaponized working exploit code. The main factor limiting real-world risk is the precondition stack: the target must have ActivityPub enabled on a Bazar form, hold at least one mirrored third-party entry, and an admin must initiate (or be CSRF-lured into) a sync with the attacker's actor. Net: credible, reporter-confirmed (VulnCheck + vendor GHSA) authorization flaw warranting prompt patching to 4.7.0, tempered by non-default configuration and required admin interaction.

An attacker stands up a malicious (or compromised previously-trusted) ActivityPub server that returns a poisoned outbox containing cross-actor Delete, Update, or Create activities. When a YesWiki admin initiates a routine sync with the attacker's actor - or is lured into clicking a GET-based CSRF link, since the sync action carries no CSRF token - the unguarded syncActorPosts handler reaches EntryManager delete/update/create sinks with no assertOwns() or sameHost() checks, letting the attacker delete, overwrite, forge, or mass-delete entries mirrored from other federated actors. A detailed public PoC reference exists in the GHSA advisory; it is not verified as working exploit code.