<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Activitypub - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/activitypub/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Thu, 09 Jul 2026 21:03:21 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/activitypub/feed.xml" rel="self" type="application/rss+xml"/><item><title>YesWiki Unauthenticated ActivityPub Signature-Verification Bypass (CVE-2026-52767)</title><link>https://feed.craftedsignal.io/briefs/2026-07-yeswiki-signature-bypass/</link><pubDate>Thu, 09 Jul 2026 21:03:21 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-07-yeswiki-signature-bypass/</guid><description>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.</description><content:encoded><![CDATA[<p>A critical vulnerability (CVE-2026-52767) has been identified in YesWiki versions 4.6.2 through 4.6.5, specifically within the <code>HttpSignatureService::verifySignature()</code> method. The flaw stems from a loose boolean negation check (<code>!openssl_verify(...)</code>) that incorrectly interprets a <code>-1</code> return value from PHP's <code>openssl_verify()</code> 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., &quot;RSA-SHA256&quot;) 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.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker establishes a public web server to host a malicious ActivityPub actor document containing a DSA public key.</li>
<li>The attacker crafts a <code>Create</code>, <code>Update</code>, or <code>Delete</code> ActivityPub request targeting the YesWiki instance's <code>POST /api/forms/{enabled-form-id}/actor/inbox</code> endpoint.</li>
<li>The malicious request includes a <code>Signature</code> header specifying <code>algorithm=&quot;RSA-SHA256&quot;</code> and points to the attacker-controlled actor document via the <code>keyId</code> parameter.</li>
<li>YesWiki's <code>HttpSignatureService::verifySignature()</code> fetches the attacker's actor document and attempts to verify the signature using PHP's <code>openssl_verify()</code> with the DSA public key and the &quot;RSA-SHA256&quot; algorithm.</li>
<li>Due to the incompatibility between the DSA key and the specified &quot;RSA-SHA256&quot; algorithm on PHP 8.3 + OpenSSL 3.x, <code>openssl_verify()</code> returns <code>int(-1)</code>.</li>
<li>YesWiki's application logic then processes <code>!openssl_verify(...)</code>, which evaluates to <code>false</code> because <code>!(-1)</code> is <code>false</code> in PHP's truthiness rules, effectively bypassing the signature verification check.</li>
<li>The attacker easily satisfies the <code>Digest</code> header enforcement by calculating a SHA-256 hash of their malicious payload.</li>
<li>YesWiki proceeds to execute the <code>processActivity()</code> method, leading to unauthorized <code>Create</code>, <code>Update</code>, or <code>Delete</code> operations on the targeted ActivityPub-enabled forms.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>The 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 <code>object.id</code> values via public outbox endpoints and then issuing <code>Delete</code> activities. Furthermore, the vulnerability can lead to triple-store pollution in the <code>yeswiki_triples</code> table with attacker-controlled <code>sourceUrl</code> 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.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Patch YesWiki instances immediately to version 4.6.6 or higher to address CVE-2026-52767.</li>
<li>Deploy the Sigma rule <code>Detect Unauthenticated YesWiki ActivityPub Inbox Access</code> to your SIEM to monitor for suspicious POST requests to the <code>/api/forms/*/actor/inbox</code> endpoint, which is a key part of the attack chain.</li>
<li>Monitor web server logs for HTTP POST requests to the <code>/api/forms/{id}/actor/inbox</code> endpoint with <code>Content-Type: application/activity+json</code> that may indicate attempted exploitation of CVE-2026-52767.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>web-vulnerability</category><category>php</category><category>activitypub</category><category>signature-bypass</category><category>cve</category><category>unauthenticated-access</category></item></channel></rss>