An unauthenticated attacker can trigger YesWiki’s public POST /api/forms/{formId}/actor/inbox route by sending a crafted HTTP Signature header whose keyId field contains an arbitrary URL. The server’s signature verification code performs an immediate outbound HTTP GET to that URL before any cryptographic checks or URL validation, enabling the attacker to make YesWiki issue arbitrary HTTP requests to any host reachable from the server. This can expose internal services, cloud‑metadata endpoints, or intranet‑only admin panels, and the attacker can learn information through timing or error oracles. The vulnerability is a classic Server‑Side Request Forgery (CWE‑918) and can compromise confidentiality, availability, and potentially allow further lateral movement if internal addresses are accessed.

YesWiki versions 4.6.2 through 4.6.5 are affected. The issue requires that ActivityPub be enabled on at least one Bazar form; if that feature is disabled the public inbox endpoint is not exposed.

The vulnerability has a CVSS score of 8.3, indicating a high severity threat. EPSS is not available and the flaw is not yet listed in CISA’s KEV catalog, but the lack of authentication for a public endpoint and the ability to reach internal resources make exploitation highly attractive. An attacker can remotely send the POST request from any network that can reach the YesWiki server, potentially scanning internal ports and fetching cloud‑metadata data without needing credentials.