CVE-2025-23221 – @fedify/fedify

Package

Manager: npm
Name: @fedify/fedify
Vulnerable Version: =1.0.13 || >=1.0.13 <1.0.14 || =1.1.10 || >=1.1.10 <1.1.11 || =1.2.10 || >=1.2.10 <1.2.11 || =1.3.3 || >=1.3.3 <1.3.4

Severity

Level: Medium

CVSS v3.1: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:L

CVSS v4.0: CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:L/SC:L/SI:N/SA:L

EPSS: 0.00111 pctl0.30223

Details

Infinite loop and Blind SSRF found inside the Webfinger mechanism in @fedify/fedify ### Summary This vulnerability allows a user to maneuver the Webfinger mechanism to perform a GET request to any internal resource on any Host, Port, URL combination regardless of present security mechanisms, and forcing the victim’s server into an infinite loop causing Denial of Service. Moreover, this issue can also be maneuvered into performing a Blind SSRF attack. ### Details The Webfinger endpoint takes a remote domain for checking accounts as a feature, however, as per the ActivityPub spec (https://www.w3.org/TR/activitypub/#security-considerations), on the security considerations section at B.3, access to Localhost services should be prevented while running in production. The **lookupWebFinger** function, responsible for returning an actor handler for received actor objects from a remote server, can be abused to perform a Denial of Service (DoS) and Blind SSRF attacks while attempting to resolve a malicious actor’s object. On Fedify, two client-facing functions implement the **lookupWebFinger** function- **getActorHandle**, and **lookupObject**, which are both used as a wrapper for the vulnerable lookup function. As the **lookupObject** function is implemented only for CLI usage, we won’t focus our PoC and explanation on it, but it is still vulnerable in the same way **getActorHandle** is. The **getActorHandle** function is a wrapper function for the **getActorHandleInternal** function (both present at _/src/vocab/actor.ts_): ```javascript async function getActorHandleInternal( actor: Actor | URL, options: GetActorHandleOptions = {}, ): Promise<`@${string}@${string}` | `${string}@${string}`> { const actorId = actor instanceof URL ? actor : actor.id; if (actorId != null) { const result = await lookupWebFinger(actorId, { userAgent: options.userAgent, tracerProvider: options.tracerProvider, }); if (result != null) { const aliases = [...(result.aliases ?? [])]; if (result.subject != null) aliases.unshift(result.subject); for (const alias of aliases) { const match = alias.match(/^acct:([^@]+)@([^@]+)$/); if (match != null) { const hostname = new URL(`https://${match[2]}/`).hostname; if ( hostname !== actorId.hostname && !await verifyCrossOriginActorHandle( actorId.href, alias, options.userAgent, options.tracerProvider, ) ) { continue; } return normalizeActorHandle(`@${match[1]}@${match[2]}`, options); } } } } if ( !(actor instanceof URL) && actor.preferredUsername != null && actor.id != null ) { return normalizeActorHandle( `@${actor.preferredUsername}@${actor.id.host}`, options, ); } throw new TypeError( "Actor does not have enough information to get the handle.", ); } ``` The **actorId** parameter containing a URL of the actor ID sinks into the **lookupWebFinger** function which is a wrapper for the **lookupWebFingerInternal**: ```javascript async function lookupWebFingerInternal( resource: URL | string, options: LookupWebFingerOptions = {}, ): Promise<ResourceDescriptor | null> { if (typeof resource === "string") resource = new URL(resource); let protocol = "https:"; let server: string; if (resource.protocol === "acct:") { const atPos = resource.pathname.lastIndexOf("@"); if (atPos < 0) return null; server = resource.pathname.substring(atPos + 1); if (server === "") return null; } else { protocol = resource.protocol; server = resource.host; } let url = new URL(`${protocol}//${server}/.well-known/webfinger`); url.searchParams.set("resource", resource.href); while (true) { logger.debug( "Fetching WebFinger resource descriptor from {url}...", { url: url.href }, ); let response: Response; try { response = await fetch(url, { headers: { Accept: "application/jrd+json", "User-Agent": typeof options.userAgent === "string" ? options.userAgent : getUserAgent(options.userAgent), }, redirect: "manual", }); } catch (error) { logger.debug( "Failed to fetch WebFinger resource descriptor: {error}", { url: url.href, error }, ); return null; } if ( response.status >= 300 && response.status < 400 && response.headers.has("Location") ) { url = new URL( response.headers.get("Location")!, response.url == null || response.url === "" ? url : response.url, ); continue; } if (!response.ok) { logger.debug( "Failed to fetch WebFinger resource descriptor: {status} {statusText}.", { url: url.href, status: response.status, statusText: response.statusText, }, ); return null; } try { return await response.json() as ResourceDescriptor; } catch (e) { if (e instanceof SyntaxError) { logger.debug( "Failed to parse WebFinger resource descriptor as JSON: {error}", { error: e }, ); return null; } throw e; } } } ``` The function takes the **actorId** parameter containing the actor ID URL, extracts the scheme and uses the rest of the URL (host+port+path) directly inside a hard-coded Webfinger URL address which in turn sinks into a fetch request. On the fetch request, the **redirect** attribute is set to “**manual**” preventing automated redirects. However, redirects are still handled using custom code that loops over responses and re-fetching the URL found inside the “Location” header until receiving a valid response or an error occurs (loop keeps until 300>status code>400). This custom redirect implementation contains multiple issues: 1.The redirect loop is endless ( while(true) loop ) without any iteration limiting, allowing attackers to perform DoS via endless redirecting. 2. A Blind SSRF attack to any URL, with arbitrary Host, Port and Path is possible via the current custom redirect implementation. 3. As the redirect handler is a custom one, it breaches the security mechanisms presented by the native redirect handler of fetch - allowing the attacker to redirect to different schemes such as data or file schemes. In order to successfully perform any of the attacks described above, an attacker needs to create a federated app which presents a malicious actor object, containing an actor ID URL of a second server which performs a recursive redirect to itself, or a URL containing an internal resource. ### PoC 1. In order to show a use case of the vulnerability, we can use the demo app presented at this URL: https://github.com/dahlia/microblog. 2. We will create two machines, victim and attacker, each one on a different server with different domains. **_Victim Machine_** 1. Create a new instance (we tested on ubuntu’s latest version), and update the package manager. 2. Install a Deno server: ` curl -fsSL https://deno.land/install.sh | sh ` ` source ~/.bashrc ` ` deno --version #check deno is working ` 3. Pull the git repository of the victim blog app: ` git clone https://github.com/dahlia/fedify.git ` 4. Modify the federation object to remove signature checks for the sake of easy testing: On file **_/examples/blog/federation/mod.ts_** edit the **_createFederation<void>_** object the following attribute: **_skipSignatureVerification: true_**. 5. Change into the blog app directory ( /examples/blog ) and run the app: ` deno task preview ` 6. Surf to the application on the browser, and register a user on the app. **_Attacker Machine_** 1. Create

Metadata

Created: 2025-01-21T19:58:29Z
Modified: 2025-01-21T19:58:29Z
Source: https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2025/01/GHSA-c59p-wq67-24wx/GHSA-c59p-wq67-24wx.json
CWE IDs: ["CWE-835", "CWE-918"]
Alternative ID: GHSA-c59p-wq67-24wx
Finding: F100
Auto approve: 1