YesWiki CVE-2026-116825

Requires the attacker to first obtain a previously valid, signed HTTP Signature request addressed to the /api/forms/{formId}/actor/inbox endpoint - the advisory names reverse-proxy logs, WAF/IDS logs, application debug logging, or shared-hosting co-tenancy (readable PHP error logs) as capture sources. The target YesWiki instance (4.6.2 up to the fix) must have ActivityPub federation active and the inbox endpoint is public (ACL 'public', no authentication), and the original signer's public key must still be published at its keyId URL (effectively unlimited, since ActivityPub keys persist). Limiting factors: the attacker cannot forge new, attacker-chosen actions - only replay captured ones (Delete, Update, Follow, Undo) - so impact is bounded by what was captured; the dependence on log/co-tenancy access to obtain a signed request is what drives AC:H/AT:P and the low EPSS despite the network vector.

Signals are mixed and point to a real-but-gated issue rather than a drop-everything emergency. The CVSS 4.0 base score is 8.3 (High) driven by VI:H (full integrity impact within the scope of captured actions) and AV:N, but the same vector carries AC:H and AT:P, meaning successful exploitation depends on conditions outside the attacker's direct control - chiefly obtaining a previously valid signed request. EPSS is low at 0.22% (13th percentile), consistent with the practical prerequisite of capturing a legitimate signed inbox request from reverse-proxy, WAF/IDS, or debug logs or via shared-hosting co-tenancy. The vuln.today decision label is this_week (not act_now/emergency), and the CVE is NOT on CISA KEV, so there is no confirmed active exploitation. A detailed public PoC reference exists in the GHSA advisory (capture-and-replay steps), but the input does not mark it as confirmed working exploit code. Net: high technical integrity/availability impact within the replayable action set, but real-world likelihood is moderated by the log/co-tenancy capture precondition and absence of KEV/high EPSS - treat as a prompt (this-week) patch, not an immediate incident. One data conflict must be verified: the metadata/EUVD state the issue is fixed in 4.7.0 and a patch is available, while the GHSA advisory body states 'Fix status: not fixed' with a confirmed affected range through 4.6.7 - confirm the fixed version with the vendor before relying on it.

An attacker with read access to server-side request logs (reverse proxy, WAF/IDS, application debug output) or shared-hosting co-tenancy captures a legitimate signed ActivityPub request - for example a Delete - sent to the public /api/forms/{formId}/actor/inbox endpoint. Because verifySignature() never checks the Date header or tracks seen signatures, the attacker replays the identical request days, weeks, or months later and the action re-executes (e.g. re-deleting an entry that was recreated). A step-by-step public PoC reference exists in the GHSA advisory, though it is not marked as confirmed working exploit code in the input.