Fedify affected by resource exhaustion caused by unbounded redirect following during remote key/document resolution
Date: 2026-04
Affected: npm/@fedify/fedify, npm/@fedify/fedify, npm/@fedify/fedify
Attack vector: dos
Category: vulnerability-disclosure
Severity: High
CVE: CVE-2026-34148
CWE: CWE-400
CWE-770
CVSS: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

### Summary `@fedify/fedify` follows HTTP redirects recursively in its remote document loader and authenticated document loader without enforcing a maximum redirect count or visited-URL loop detection. An attacker who controls a remote ActivityPub key or actor URL can force a server using Fedify to make repeated outbound requests from a single inbound request, leading to resource consumption and denial of service. ### Details Fedify verifies ActivityPub HTTP signatures by fetching the remote `keyId` during request processing. The relevant flow is `handleInboxInternal()` -> `verifyRequest()` -> `fetchKeyInternal()` -> document loader. In affected versions: - the generic document loader recursively follows `3xx` responses by calling `load()` again on the `Location` header - the authenticated redirect path (`doubleKnock()`) also recursively follows redirects - neither path enforces a redirect cap or tracks visited URLs to detect self-referential redirect loops As a result, if an attacker-controlled `keyId` or actor URL responds with `302 Location: <same URL>`, a single ActivityPub request can trigger tens or hundreds of outbound requests before the fetch completes or the request times out. I confirmed the issue in `@fedify/fedify` 1.9.1 and 1.9.2. By contrast, Fedify's WebFinger lookup path already has a redirect cap, which suggests the missing bound in the document loader is unintended. Failed key fetches are not durably negatively cached. After a failed lookup, the null


Mitigations:

Architectural layers (MAESTRO):