CVE-2026-47746

This vulnerability is a signature bypass through JSON-LD compaction — a well-documented but persistently overlooked flaw in how cryptographic verification interacts with context-sensitive document transformation. When Misskey verifies a signed ActivityPub object, it validates the signature against one representation of the document. When it later processes that object, JSON-LD compaction may rewrite the document — transforming IRIs, adding implied predicates, restructuring data — into a semantically equivalent but syntactically different form. The signature validates on form A, but the application acts on form B. The trust chain is broken, and malicious content passes as verified. The root cause is that JSON-LD compaction is deterministic only under an identical active context. In ActivityPub federation, context documents can be fetched from the network during processing. An attacker who controls or interposes on document delivery can serve one context to the verifier and another to the processor — exploiting a context-state mismatch rather than requiring precise timing. This means the vulnerability is exploitable by any actor who can influence what context resolution a server performs, not just attackers with nanosecond-precision timing. For defenders running ActivityPub software: audit your JSON-LD library usage specifically. Check whether signature verification and document processing operate on the same representation. If your library exposes verify() and compact() as separate calls, you're likely vulnerable — verify the signature, then compact the same document object, not a fresh parse of the same data. Ideally, use a library that binds these atomically. The 2026.5.4 Misskey patch addressed this, but the underlying library design pattern is pervasive. The federated nature of ActivityPub amplifies this: a single compromised server can inject fraudulent content that hundreds of downstream instances accept as verified. Your patch cadence is irrelevant if your federated peers remain vulnerable — you're only as secure as the least-patched server in your trust graph. This is not a new vulnerability class — it's the same representation-change bypass that plagued XML Signatures. The JSON-LD spec inherited this history and designed context-sensitive processing anyway. Libraries then exposed verify() as content-agnostic, making incorrect usage the path of least resistance. Expect similar issues in other ActivityPub implementations that haven't audited this specific interaction.

Reviewed through automated stages and approved by a human before publication.