CVE-2026-52769 in YesWiki
Summary
by MITRE • 09/05/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/05/2026
YesWiki, a wiki system implemented in PHP, contains a critical server-side request forgery vulnerability affecting versions from 4.6.2 up to but not including 4.6.6. The flaw resides within the POST /api/forms/{formId}/actor/inbox route, which is publicly accessible with an access control level of public. This endpoint accepts HTTP Signature headers as part of its authentication mechanism for ActivityPub interactions. Specifically, the keyId parameter within this header is expected to reference a cryptographic key but is instead processed in a manner that allows it to function as a URL target. The HttpSignatureService::verifySignature() method parses this header and immediately initiates an outbound HTTP GET request to the specified URL before performing any subsequent cryptographic verification or strict URL validation checks. This architectural flaw effectively bypasses standard security controls designed to prevent unauthorized network interactions, creating a direct vector for Server-Side Request Forgery attacks.
The operational impact of this vulnerability is severe due to its unauthenticated nature and broad reachability within internal networks. An attacker can exploit this flaw to force the YesWiki server to issue arbitrary HTTP requests to any destination that the underlying host can access. This includes sensitive internal services, intranet-only administrative panels, and cloud metadata endpoints such as 169.254.169.254 commonly found in AWS EC2 instances or similar cloud environments. By leveraging timing attacks and analyzing error message responses from these requests, an attacker can perform port scanning to identify open services on internal hosts. Furthermore, the ability to reach cloud metadata endpoints allows for the enumeration of instance identity credentials, potentially leading to full compromise of the underlying infrastructure if IAM roles with excessive permissions are attached to the instance. The only prerequisite for exploitation is that ActivityPub functionality be enabled on at least one Bazar form within the YesWiki deployment, a feature often used for federated social networking capabilities but which inadvertently exposes this dangerous API endpoint.
This vulnerability aligns closely with CWE-918 Server-Side Request Forgery (SSRF), specifically illustrating how improper validation of user-supplied input leads to unauthorized network access from the server side. It also maps to MITRE ATT&CK technique T1557, which covers Adversary-in-the-Middle scenarios where an attacker intercepts or manipulates communication between two parties, although in this context it is more accurately described as using a trusted internal service as a proxy for external reconnaissance and credential theft via T1046 Network Service Discovery. The exploitation chain demonstrates how seemingly benign API parameters can be weaponized to pivot through network boundaries that are typically protected by firewalls or security groups from direct external access.
Mitigation strategies must prioritize immediate patching of the YesWiki installation to version 4.6.6 or later, where this logic has been corrected to ensure proper validation before making outbound requests. In environments where upgrading is not immediately feasible, administrators should disable ActivityPub features on Bazar forms if they are not actively required for their use case, thereby removing the exposed endpoint from public access. Additionally, implementing strict egress filtering at the network perimeter can limit the destinations the server can reach, reducing the blast radius of any successful SSRF exploitation. Monitoring outbound traffic patterns from web servers to unusual internal IP ranges or cloud metadata endpoints should also be established as a standard security practice to detect potential abuse attempts in real time.