YesWiki CVE-2026-104463

Exploitation requires the target YesWiki instance (before 4.6.7) to expose the public forms actor ActivityPub inbox route and to process signed Follow activities; the attacker signs the request with their own keyId (so no victim credentials or authentication are needed per PR:N) but must supply an internal actor URL in the body that the server will dereference. Impact is maximized when YesWiki runs in a cloud environment with an accessible instance metadata service (e.g., 169.254.169.254) or reachable internal hosts; isolated/segmented deployments without sensitive internal endpoints substantially limit the real-world confidentiality impact. The AC:H/AT:P metrics reflect that the request must satisfy the signature/ActivityPub handling path and that a useful internal target must exist, which constrains reliability.

Signals are mixed and lean toward a moderate, not top-tier, priority. The CVSS 4.0 base score is 8.3 (High), and the vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H) confirms an unauthenticated, network-reachable SSRF with high confidentiality impact, which is serious because it can reach cloud metadata endpoints. However, the same vector tempers this: AC:H and AT:P indicate the attack is not trivially repeatable and depends on specific conditions (valid ActivityPub signature handling and a reachable internal target), so it is not a point-and-click mass-exploitation bug. No EPSS score was provided in the input, so exploitation probability cannot be quantified. The CVE is NOT in CISA KEV and no public exploit code is referenced, so there is no evidence of active exploitation - this is a disclosed-and-patched issue reported by VulnCheck, not an in-the-wild campaign. Net: prioritize patching for internet-exposed YesWiki instances (especially cloud-hosted ones where metadata theft could yield credentials), but this is a high-CVSS issue with no confirmed real-world exploitation signal rather than an emergency.

An unauthenticated attacker crafts a signed ActivityPub 'Follow' activity, signing it with their own keyId while placing an internal actor URL (e.g., a cloud metadata endpoint like 169.254.169.254 or an internal service) in the request body, then POSTs it to the public forms actor inbox route. The server dereferences the attacker-supplied URL via blind GET/POST requests, enabling internal network reconnaissance or theft of cloud instance credentials. No public exploit code is referenced in the available data.