If you use an affected Fedify release, update now. Two server-side request forgery vulnerabilities have been addressed: GHSA-r48c-xx2h-fv4g, a DNS rebinding bypass of Fedify's private address checks, and GHSA-cj5r-cw77-6gwp, unvalidated page and favicon requests in fedify nodeinfo. Deno deployments need additional network restrictions; upgrading Fedify alone does not close the DNS rebinding vulnerability.
The patched releases are 2.0.35, 2.1.31, 2.2.20, 2.3.15, and 2.4.5. Update to the corresponding release on your minor line, with the runtime mitigations described below. The affected releases on these lines are 2.0.34 and earlier, 2.1.30 and earlier, 2.2.19 and earlier, 2.3.14 and earlier, and 2.4.4 and earlier. For ongoing support, the security policy covers the latest two minor lines, 2.3 and 2.4. Users on releases before 2.0 should move to a supported release.
DNS rebinding bypasses SSRF protection (GHSA-r48c-xx2h-fv4g, medium, CVSS 5.4)
Fedify checked that a hostname resolved only to public addresses, then let fetch() resolve it again when connecting. An attacker controlling the hostname's DNS answers could return a public address for validation and a private or loopback address for the connection, causing requests to reach internal services. Redirects and alternate-document links were subject to the same gap.
This affects document loading, including authenticated document loading, outbound activity delivery, NodeInfo lookups, and WebFinger lookups in @fedify/fedify, @fedify/vocab-runtime, and @fedify/webfinger. On Node.js and Bun, the fix makes connections only to addresses that passed validation. Calling validatePublicUrl() before an application's own fetch() still does not pin that connection. Setting allowPrivateAddress: true continues to permit private destinations.
On Bun, deployments with HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY set, including their lowercase forms, should upgrade to Bun 1.4.3 or later. Alternatively, unset those variables for the Fedify process or configure the proxy to refuse private destinations. Older Bun versions may send requests through a proxy that resolves the hostname again. On Bun versions before 1.3.11, Fedify now refuses HTTPS requests to non-default ports because those Bun versions cannot verify a pinned connection's certificate against the original hostname. See the Bun deployment guidance.
Deno's fetch() cannot pin connections to validated addresses. Use Deno 2.8.1 or later with the documented --deny-net list and a Unix domain socket behind a reverse proxy, plus network-level restrictions for private IPv6 ranges. If that setup is unsuitable, apply equivalent outbound restrictions at the firewall or container network layer. Follow the Deno deployment mitigation.
Unvalidated page and favicon requests (GHSA-cj5r-cw77-6gwp, low, CVSS 3.1)
An operator running fedify nodeinfo against a malicious instance could cause the CLI to send a GET request to a loopback, link-local, or private address from the operator's machine. The NodeInfo lookup validated destinations, but the subsequent page and favicon requests used plain fetch() with automatic redirects. A malicious favicon URL or page redirect could therefore reach an internal endpoint.
The attacker does not directly receive the response body, but the request can affect an internal endpoint with GET side effects. The fix validates page, favicon, and redirect destinations, skipping the favicon when a destination is private while still showing the NodeInfo document. Upgrade @fedify/cli separately from the library. Until then, --no-favicon or --raw avoids these page and favicon requests. The Bun and Deno caveats above also apply to the CLI.
Updating
Use the command for your package manager to install 2.4.5 explicitly:
npm install @fedify/fedify@2.4.5
yarn add @fedify/fedify@2.4.5
pnpm add @fedify/fedify@2.4.5
bun add @fedify/fedify@2.4.5
deno add jsr:@fedify/fedify@2.4.5
If you stay on another minor line, substitute 2.0.35, 2.1.31, 2.2.20, or 2.3.15 as appropriate. Update direct dependencies on @fedify/vocab-runtime and @fedify/webfinger to the same release as well. Check the resolved versions in your lockfile, since an ordinary update command can stay within a vulnerable dependency range or leave a transitive dependency locked. Apply the runtime mitigations above and redeploy all web and worker processes.
For an npm-installed global CLI:
npm install -g @fedify/cli@2.4.5
For other installation methods, reinstall the corresponding patched version using the CLI installation instructions. Check fedify --version before using it against an untrusted instance.
Thanks to @finalchild for reporting the DNS rebinding issue and to Zachariah Mithani for reporting the favicon request issue.
If anything is unclear, ask below.