Description

YesWiki is a wiki system written in PHP. From version 4.6.2 to before version 4.6.6, the POST /api/forms/{formId}/actor/inbox route - exposed publicly with acl:"public" - accepts an HTTP Signature header whose keyId parameter is a URL. HttpSignatureService::verifySignature() parses the header and immediately makes a server-side HTTP GET to that URL, before any cryptographic verification or URL validation. An unauthenticated remote attacker can therefore make YesWiki issue arbitrary outbound HTTP requests to any host the server can reach - internal services, cloud-metadata endpoints (169.254.169.254), intranet-only admin panels, etc. - and read enough back via timing and error-message oracles to scan ports, enumerate services, and (on a real cloud instance) reach IAM metadata. The only deployment-side precondition is that ActivityPub be enabled on at least one Bazar form. This issue has been patched in version 4.6.6.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.3",
  "pubDate": "2026-09-05T00:17:19.683Z",
  "pubdate": "2026-09-05T00:17:19.683Z",
  "executiveSummary": "YesWiki versions 4.6.2 through 4.6.5 are vulnerable to an unauthenticated Server-Side Request Forgery (SSRF) flaw due to improper handling of the HTTP Signature header within the ActivityPub implementation.\nThe vulnerability originates in the HttpSignatureService::verifySignature() function, which performs an unsanitized HTTP GET request to a user-supplied URL provided in the keyId parameter of the signature header.\nThis flaw allows remote, unauthenticated attackers to force the server to perform arbitrary outbound HTTP requests to internal network resources, local services, or cloud infrastructure metadata endpoints.\nThe risk is critical, as it enables attackers to perform port scanning, enumerate internal services, and potentially exfiltrate sensitive data, including cloud IAM credentials, by leveraging timing and error-message oracles.\nExploitation requires the target YesWiki instance to have the ActivityPub feature enabled on at least one Bazar form. The attack is fully unauthenticated and does not require prior knowledge of the internal network architecture.",
  "technicalDetails": "The vulnerability resides within the HttpSignatureService::verifySignature() method in the YesWiki codebase. When the system processes a request to the POST /api/forms/{formId}/actor/inbox route, it expects an HTTP Signature header. The application logic parses this header to retrieve the keyId parameter, which is intended to identify the public key associated with the actor. However, the implementation fails to validate or sanitize the URI provided in this field.\nSpecifically, the application performs an immediate, server-side HTTP GET request to the URL specified in the keyId parameter before conducting any cryptographic verification of the signature itself. Because this route is publicly accessible under the 'public' ACL, an unauthenticated attacker can supply an arbitrary URL as the keyId value.\nThe attack flow proceeds as follows: 1) The attacker crafts a malicious POST request to the vulnerable endpoint with a crafted HTTP Signature header containing a target URI (e.g., http://169.254.169.254/latest/meta-data/ for AWS metadata or internal IP addresses like http://127.0.0.1:port for service enumeration). 2) The YesWiki server receives the request and triggers the HttpSignatureService to process the signature. 3) The server blindly initiates an outbound HTTP request to the attacker-supplied URI. 4) The application processes the response from the target; by monitoring response times or analyzing error messages returned by the application, the attacker can infer the state of internal services or extract the contents of the fetched resources.\nThis behavior facilitates a range of post-exploitation activities, including blind or semi-blind SSRF. Attackers can conduct network reconnaissance to map the internal topology, identify exposed management interfaces within the intranet that are otherwise unreachable, or interact with cloud-native metadata services to obtain sensitive configuration data or IAM identity tokens.\nThe vulnerability affects YesWiki versions 4.6.2 through 4.6.5. It is triggered regardless of the caller's authentication state, as the vulnerable route is exposed publicly and the processing of the Signature header occurs before the application logic enforces any authentication checks or structural validations on the signature payload.\nThe vulnerability is successfully remediated in version 4.6.6, which implements stricter validation of the keyId parameter and ensures that the server-side request is only initiated under secure and expected conditions."
}