Description

YesWiki before 4.6.7 contains a server-side request forgery vulnerability that allows unauthenticated attackers to trigger server requests by sending signed Follow activities to the public forms actor inbox route. Attackers sign requests with their own keyId while supplying internal actor URLs in the body, reaching internal hosts or cloud metadata via blind GET and POST requests.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.0",
  "pubDate": "2026-10-02T12:17:18.643Z",
  "pubdate": "2026-10-02T12:17:18.643Z",
  "executiveSummary": "YesWiki versions prior to 4.6.7 are susceptible to a Server-Side Request Forgery (SSRF) vulnerability due to improper validation of user-supplied data in ActivityPub interactions.\nThe vulnerability resides in the processing of signed 'Follow' activities routed to the public forms actor inbox.\nUnauthenticated attackers can leverage this flaw to force the YesWiki server to perform arbitrary GET and POST requests against internal network resources and cloud metadata services.\nBy signing malicious requests with their own keyId, attackers bypass standard authentication mechanisms to interact with internal infrastructure that is otherwise unreachable from the public internet.\nThe primary impact includes potential information disclosure, interaction with internal services, and unauthorized access to cloud provider metadata APIs, which may lead to privilege escalation or further compromise of the hosting environment.\nExploitation requires no prior authentication and relies on the server's trust in signed ActivityPub messages to trigger outbound requests.",
  "technicalDetails": "The root cause of this vulnerability is the insecure handling of 'Follow' activity payloads within the ActivityPub implementation in YesWiki versions before 4.6.7. Specifically, the application logic fails to perform adequate server-side validation or sanitization of the URLs provided within the ActivityPub activity object when processing incoming requests to the public forms actor inbox.\nThe attack flow begins when an attacker constructs a malicious ActivityPub 'Follow' activity. Because the application processes these requests based on a provided keyId for signature verification, an attacker can generate a validly signed request using their own cryptographic credentials. When this payload is submitted to the specific actor inbox route, the YesWiki server attempts to process the activity.\nThe application logic fails to restrict the destination of the resulting network activity. Upon receiving the signed request, the internal processing component of the YesWiki actor inbox interprets the embedded actor URLs as legitimate targets for subsequent server-side requests. This allows the attacker to instruct the YesWiki server to initiate blind GET or POST requests to arbitrary destinations.\nThe attack leverages the server's internal network position, enabling requests to be routed to local services (e.g., localhost or internal microservices) or sensitive cloud metadata endpoints (e.g., 169.254.169.254). Since the requests originate from the YesWiki server's backend, they bypass perimeter firewalls and network access control lists that would typically block direct external access to these internal resources.\nThe payload behavior involves supplying internal or cloud-specific URLs within the activity body. The server, trusting the signature and the internal processing flow, performs the HTTP request on behalf of the attacker. Post-exploitation impact varies based on the target of the SSRF; it may result in the leakage of sensitive data, such as cloud identity tokens or service configuration details, which can lead to a full compromise of the affected host or associated cloud infrastructure."
}