Summary 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 im…
| CVE ID | CVE-2026-52769 |
| Vendor | composer |
| Affected Product | yeswiki/yeswiki |
| Vulnerability Type | Vulnerability |
| CVSS Score | 8.3 (HIGH) |
| Actively Exploited | ❌ No known exploitation |
| Patch Status | See Vendor Advisory → |
| Reported By | CYBERDUDEBIVASH SENTINEL APEX Intelligence (via github_advisories) |
#
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 enab
Sigma rules, YARA signatures, IOC table, and SIEM queries for Splunk, Elastic, Sentinel, and Chronicle — deployable in 5 minutes.