{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/activitypub/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["composer/yeswiki/yeswiki (\u003e= 4.6.2, \u003c 4.6.6)"],"_cs_severities":["high"],"_cs_tags":["web-vulnerability","php","activitypub","signature-bypass","cve","unauthenticated-access"],"_cs_type":"advisory","_cs_vendors":["YesWiki"],"content_html":"\u003cp\u003eA critical vulnerability (CVE-2026-52767) has been identified in YesWiki versions 4.6.2 through 4.6.5, specifically within the \u003ccode\u003eHttpSignatureService::verifySignature()\u003c/code\u003e method. The flaw stems from a loose boolean negation check (\u003ccode\u003e!openssl_verify(...)\u003c/code\u003e) that incorrectly interprets a \u003ccode\u003e-1\u003c/code\u003e return value from PHP's \u003ccode\u003eopenssl_verify()\u003c/code\u003e function as a successful verification. This bypass is triggered when specific conditions are met, such as using a DSA or EC public key with an RSA-only algorithm (e.g., \u0026quot;RSA-SHA256\u0026quot;) on PHP 8.3 with OpenSSL 3.x. An attacker can leverage this to perform unauthenticated Create, Update, and Delete (CRUD) operations on any ActivityPub-enabled YesWiki form. This vulnerability allows for malicious content injection, defacement, spam, SEO poisoning, and data manipulation, posing a significant risk to the integrity and reputation of affected YesWiki instances.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker establishes a public web server to host a malicious ActivityPub actor document containing a DSA public key.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a \u003ccode\u003eCreate\u003c/code\u003e, \u003ccode\u003eUpdate\u003c/code\u003e, or \u003ccode\u003eDelete\u003c/code\u003e ActivityPub request targeting the YesWiki instance's \u003ccode\u003ePOST /api/forms/{enabled-form-id}/actor/inbox\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eThe malicious request includes a \u003ccode\u003eSignature\u003c/code\u003e header specifying \u003ccode\u003ealgorithm=\u0026quot;RSA-SHA256\u0026quot;\u003c/code\u003e and points to the attacker-controlled actor document via the \u003ccode\u003ekeyId\u003c/code\u003e parameter.\u003c/li\u003e\n\u003cli\u003eYesWiki's \u003ccode\u003eHttpSignatureService::verifySignature()\u003c/code\u003e fetches the attacker's actor document and attempts to verify the signature using PHP's \u003ccode\u003eopenssl_verify()\u003c/code\u003e with the DSA public key and the \u0026quot;RSA-SHA256\u0026quot; algorithm.\u003c/li\u003e\n\u003cli\u003eDue to the incompatibility between the DSA key and the specified \u0026quot;RSA-SHA256\u0026quot; algorithm on PHP 8.3 + OpenSSL 3.x, \u003ccode\u003eopenssl_verify()\u003c/code\u003e returns \u003ccode\u003eint(-1)\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eYesWiki's application logic then processes \u003ccode\u003e!openssl_verify(...)\u003c/code\u003e, which evaluates to \u003ccode\u003efalse\u003c/code\u003e because \u003ccode\u003e!(-1)\u003c/code\u003e is \u003ccode\u003efalse\u003c/code\u003e in PHP's truthiness rules, effectively bypassing the signature verification check.\u003c/li\u003e\n\u003cli\u003eThe attacker easily satisfies the \u003ccode\u003eDigest\u003c/code\u003e header enforcement by calculating a SHA-256 hash of their malicious payload.\u003c/li\u003e\n\u003cli\u003eYesWiki proceeds to execute the \u003ccode\u003eprocessActivity()\u003c/code\u003e method, leading to unauthorized \u003ccode\u003eCreate\u003c/code\u003e, \u003ccode\u003eUpdate\u003c/code\u003e, or \u003ccode\u003eDelete\u003c/code\u003e operations on the targeted ActivityPub-enabled forms.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe successful exploitation of CVE-2026-52767 allows for unauthenticated CRUD operations on bazar entries of any ActivityPub-enabled YesWiki form. This can result in widespread defacement and content injection across public-facing wikis, including potential spam and SEO poisoning through manipulated entry bodies which are HTML-rendered and indexed by search engines. Attackers can also erase legitimate federated content by discovering \u003ccode\u003eobject.id\u003c/code\u003e values via public outbox endpoints and then issuing \u003ccode\u003eDelete\u003c/code\u003e activities. Furthermore, the vulnerability can lead to triple-store pollution in the \u003ccode\u003eyeswiki_triples\u003c/code\u003e table with attacker-controlled \u003ccode\u003esourceUrl\u003c/code\u003e entries, which can interfere with future federation flows and degrade the wiki's overall reputation due to the appearance of receiving signed content from a remote, yet attacker-controlled, actor.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePatch YesWiki instances immediately to version 4.6.6 or higher to address CVE-2026-52767.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Unauthenticated YesWiki ActivityPub Inbox Access\u003c/code\u003e to your SIEM to monitor for suspicious POST requests to the \u003ccode\u003e/api/forms/*/actor/inbox\u003c/code\u003e endpoint, which is a key part of the attack chain.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for HTTP POST requests to the \u003ccode\u003e/api/forms/{id}/actor/inbox\u003c/code\u003e endpoint with \u003ccode\u003eContent-Type: application/activity+json\u003c/code\u003e that may indicate attempted exploitation of CVE-2026-52767.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-09T21:03:21Z","date_published":"2026-07-09T21:03:21Z","id":"https://feed.craftedsignal.io/briefs/2026-07-yeswiki-signature-bypass/","summary":"A critical vulnerability, CVE-2026-52767, in YesWiki's `HttpSignatureService::verifySignature()` allows unauthenticated attackers to bypass ActivityPub signature verification due to a loose boolean negation (`!openssl_verify(...)`) accepting `int(-1)` from PHP's `openssl_verify()` under specific conditions, enabling arbitrary Create, Update, and Delete operations on ActivityPub-enabled forms leading to defacement and content manipulation.","title":"YesWiki Unauthenticated ActivityPub Signature-Verification Bypass (CVE-2026-52767)","url":"https://feed.craftedsignal.io/briefs/2026-07-yeswiki-signature-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed - Activitypub","version":"https://jsonfeed.org/version/1.1"}