Canonical CVE-2026-42462

{
  "product_name": "Fedify",
  "summary": "Linked Data Signature forgery in Fedify (the @fedify/fedify ActivityPub server framework) before 2.2.3 lets remote unauthenticated attackers reshape a third-party-signed activity so it is interpreted differently while its signature still verifies. Because the signature covers the canonical RDF graph rather than the JSON-LD serialization, an attacker who has received a signed activity can use JSON-LD keywords (@graph, @reverse, @included) or context-alias tricks to promote, hide, or rewrite fields and have the forged result accepted as authentic. There is no public exploit identified at time of analysis and the issue is not in CISA KEV, but the GitHub Security Advisory documents the exact restructuring techniques in detail.",
  "technical_context": "Fedify is a TypeScript/JavaScript framework (npm package @fedify/fedify, CPE pkg:npm/@fedify_fedify) for building ActivityPub/fediverse servers, where federated servers authenticate inbound activities using Linked Data Signatures. An LD-Signature is computed over the canonicalized RDF dataset (RDF Dataset Normalization) derived from a JSON-LD document, not over the JSON bytes. The root cause maps to CWE-180 (Incorrect Behavior Order: Validate Before Canonicalize): JSON-LD permits many different document serializations of the same underlying graph, so keywords such as @graph (named graphs), @reverse (reversed relations), and @included (out-of-tree statements) let an attacker move the effective root node or hide properties while the canonical graph — and therefore the signature — stays valid. Compounding this, Fedify did not verifiably compact signed documents against the application's local JSON-LD context before processing, so attacker-chosen aliases and non-mapped terms could relabel or replace values; the same class of flaw was previously fixed in Mastodon (PR #17426).",
  "risk_assessment": "The CVSS 3.1 score is 7.0 (High) with vector AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:L — network reachable and unauthenticated (PR:N), but high attack complexity (AC:H) because the attacker must already possess a valid third-party-signed activity and craft a structure-preserving transformation, and impact is integrity-centric (I:H) with only low confidentiality and availability impact. No EPSS score was provided in the input and the CVE is not listed in CISA KEV, so there is no signal of widespread automated exploitation; no public exploit code was identified, though the advisory describes the techniques concretely enough to guide an attacker. CONFLICTING SIGNAL: the input 'RCE' tag is inconsistent with both the description and the CVSS impact metrics (C:L/I:H/A:L), which describe signature forgery and activity tampering, not remote code execution — treat the RCE tag as a likely mislabel. Net assessment: a real, integrity-focused priority specifically for operators running Fedify-based fediverse servers, but exploitation is conditional (it needs a pre-existing signed activity to manipulate) rather than a spray-and-pray internet-wide threat.",
  "affected_products": "The affected product is the Fedify ActivityPub framework distributed as the npm package @fedify/fedify (CPE pkg:npm/@fedify_fedify). All versions prior to 2.2.3 are vulnerable, and the issue is fixed in 2.2.3. Details are published in GitHub Security Advisory GHSA-9rfg-v8g9-9367 (https://github.com/fedify-dev/fedify/security/advisories/GHSA-9rfg-v8g9-9367) and the fixed release at https://github.com/fedify-dev/fedify/releases/tag/2.2.3.",
  "remediation": "Vendor-released patch: 2.2.3 (released May 21, 2026) — upgrade @fedify/fedify to 2.2.3 or later, which rejects activities containing @graph, @included, and @reverse and compacts verified documents against the application context. If you cannot upgrade immediately, apply the same controls the vendor recommends: after compacting each incoming signed activity to your application's local JSON-LD context (compacting first is required because aliases can disguise these keywords), reject any document that still contains @graph, @included, or @reverse, and always compact LD-Signature-verified documents against your local context before processing so attacker-renamed aliases and non-mapped terms cannot substitute values. The trade-off of rejecting these keywords is minimal in practice — the vendor observed no legitimate ActivityPub use of @graph, @included, or @reverse — but custom integrations that rely on named graphs would break. See GHSA-9rfg-v8g9-9367 (https://github.com/fedify-dev/fedify/security/advisories/GHSA-9rfg-v8g9-9367) and the release notes at https://github.com/fedify-dev/fedify/releases/tag/2.2.3.",
  "exploit_scenario": "A malicious or compromised fediverse server takes a legitimately signed activity it received over federation — for example Mastodon's Undo wrapping an Announce ({\"type\":\"Undo\",\"object\":{\"type\":\"Announce\"}}) — and rewrites it by moving the top-level Undo into a @graph property and promoting the embedded Announce to the document root. The signature still verifies because the canonical RDF graph is unchanged, so the receiving server processes the standalone Announce and ignores the original Undo, effectively replaying or forging the action. No public proof-of-concept code was identified, but the advisory documents the transformation steps explicitly.",
  "exploitation_conditions": "The attacker must first possess a genuine third-party-signed activity received via federation, and for the @graph/@reverse vector that activity must contain an embedded object or nested activity that can be promoted (the canonical Mastodon example is Undo{Announce}); the @included vector instead requires a signed Create or Update whose attributes can be hidden. No authentication is required against the victim (PR:N) and no user interaction is needed (UI:N). Exploitation is limited by high attack complexity (AC:H): success depends on which specific activity types a given server actually signs and processes, the attacker must craft a JSON-LD restructuring that preserves the canonical graph, and the impact varies by implementation — so this is not unauthenticated remote exploitation against a default configuration, but rather conditional forgery that hinges on obtaining and reshaping a suitable pre-signed activity.",
  "attack_chain": "Receive third-party signed activity → Wrap activity in @graph or hide fields via @included → Canonical RDF graph unchanged so signature stays valid → Relay restructured payload to target inbox → Server processes attacker-controlled forged activity",
  "confidence_notes": "CONFIRMED: fixed version 2.2.3 and the May 21, 2026 release are confirmed by the vendor's GitHub release notes and advisory GHSA-9rfg-v8g9-9367, and the affected range (< 2.2.3) comes directly from the GHSA. INFERRED: authentication and complexity characterizations are taken from the supplied CVSS vector (PR:N, AC:H). UNKNOWN/MISSING: no EPSS score was provided, the CVE is not in CISA KEV, and no public exploit code was identified (the advisory describes the technique but references no PoC); additionally, the 'RCE' input tag is unverified and contradicts the CVSS impact metrics and description, so it should not be relied upon."
}