CVE-2026-52769

YesWiki versions 4.6.2 up to (but not including) 4.6.6 contain an unauthenticated server-side request forgery (CWE-918) in the POST /api/forms/{formId}/actor/inbox route, which is exposed publicly once ActivityPub is enabled on at least one Bazar form. When handling a request, HttpSignatureService::verifySignature() parses the HTTP Signature header and immediately issues a server-side HTTP GET to the URL supplied in the keyId parameter, before any cryptographic verification or URL validation takes place. An unauthenticated remote attacker can therefore force the YesWiki server to send arbitrary HTTP requests to any host it can reach — internal services, intranet-only admin panels, or the cloud metadata endpoint at 169.254.169.254 — and infer responses through timing and error-message oracles to port-scan, enumerate services, and potentially reach IAM metadata on cloud-hosted instances; CVSS 3.1 rates this 8.3 (high) with changed scope, reflecting reach into other systems. Any deployment running an affected version with ActivityPub enabled on a Bazar form is exposed, and the issue is fixed in version 4.6.6. No public proof-of-concept or in-the-wild exploitation is currently known (EPSS 0.3%, not in CISA KEV).

What to do: Upgrade to YesWiki 4.6.6 or later; deployments that cannot upgrade should disable ActivityPub on Bazar forms or restrict access to the /api/forms/{formId}/actor/inbox route at the reverse proxy. As defense in depth, apply egress filtering from the web host to link-local/cloud metadata addresses (169.254.169.254) and internal networks, and review logs for unexplained outbound HTTP GETs issued around the time of POSTs to the actor inbox endpoint.