CVE-2026-34148: 
JavaScript vulnerability analysis and mitigation

CVE-2026-34148 is a resource exhaustion vulnerability in Fedify, a TypeScript library for building ActivityPub-powered federated server applications. The flaw exists in Fedify's remote document loader and authenticated document loader, which follow HTTP redirects recursively without enforcing a maximum redirect count or detecting visited-URL loops. Affected versions include @fedify/fedify prior to 1.9.6, 1.10.5, 2.0.8, and 2.1.1, as well as @fedify/vocab-runtime prior to 2.0.8 and 2.1.1. The vulnerability was discovered by @wrathsec (Abhinav Jaswal), surfaced through a Ghost ActivityPub user report, and publicly disclosed on April 6, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat CVE).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). The vulnerable code path is handleInboxInternal() → verifyRequest() → fetchKeyInternal() → document loader: both the generic document loader (which calls load() recursively on Location headers) and the authenticated redirect path (doubleKnock()) follow 3xx responses without any redirect cap or loop detection. An attacker who controls a remote ActivityPub keyId or actor URL can serve a self-referential redirect chain (e.g., 302 Location: /actor pointing back to itself), causing the victim server to issue tens or hundreds of outbound HTTP requests per single inbound ActivityPub request. Notably, Fedify's WebFinger lookup path already enforced a redirect cap, indicating the missing bound in the document loader was unintentional. Additionally, failed key fetches are only negatively cached in a request-local cache, meaning the same redirect loop can be re-triggered on subsequent requests (GitHub Advisory).

Successful exploitation results in a denial-of-service condition affecting availability (CVSS availability impact: High), with no confidentiality or integrity impact. An unauthenticated attacker can force a Fedify-based server to exhaust CPU time, worker threads, connection slots, and outbound bandwidth by triggering unbounded redirect chains during ActivityPub key or document resolution. Because failed lookups are not durably negatively cached, the attack can be repeated across multiple requests for the same keyId, compounding resource exhaustion. Any Fedify-based server that verifies remote keys or loads remote ActivityPub documents — including applications built on Ghost's ActivityPub integration — is within scope (GitHub Advisory).

A proof-of-concept (PoC) exploit is publicly available in the GitHub Security Advisory, consisting of two complete, runnable Node.js scripts that demonstrate the vulnerability by creating a local HTTP server with redirect loops and calling the vulnerable Fedify document loader functions — confirming 119 self-redirects from a single request (120 total outbound requests). No authentication or special privileges are required to exploit this vulnerability. There is no evidence of active in-the-wild exploitation at this time, and the CVE is not listed in the CISA KEV catalog. The EPSS score is approximately 0.04%, reflecting low current exploitation probability (GitHub Advisory).

1. Set up a malicious ActivityPub server: Deploy an HTTP server that responds to any request with a 302 Found redirect pointing back to itself (e.g., 302 Location: http://<attacker-server>/actor), creating an infinite redirect loop.
2. Register a malicious actor or key: Create or control an ActivityPub actor or cryptographic key (keyId) whose URL resolves to the attacker-controlled redirect server.
3. Send an ActivityPub activity to the target: Craft and send a signed ActivityPub activity (e.g., a Follow or Create request) to the inbox of a Fedify-based server, using the malicious keyId in the HTTP Signature header.
4. Trigger key resolution: The target Fedify server attempts to verify the HTTP signature by fetching the keyId URL via its document loader, which begins following the redirect chain recursively.
5. Exhaust server resources: The document loader follows the redirect loop without limit (up to ~120 requests per inbound request in tested versions), consuming CPU, connection slots, and outbound bandwidth. Repeating this with multiple requests or across multiple keyId values amplifies the denial-of-service effect.
6. Sustain the attack: Because failed key fetches are only cached in a request-local cache, subsequent inbound requests with the same malicious keyId re-trigger the full redirect loop, sustaining resource exhaustion (GitHub Advisory).

• Network: Unusually high volume of outbound HTTP requests from the Fedify application server to a single external host or IP, particularly to ActivityPub actor or key URLs; repeated 302 redirect responses observed in outbound traffic logs from a single source URL.
• Network: Outbound connections to attacker-controlled domains serving only HTTP redirect responses with no final content delivery.
• Logs: Application logs showing repeated fetch attempts to the same keyId or actor URL within a single request lifecycle; log entries indicating timeouts or connection exhaustion during remote document loading.
• Logs: High frequency of verifyRequest or fetchKeyInternal log entries associated with the same remote keyId across multiple inbound ActivityPub inbox requests.
• Process/Resource: Elevated CPU and memory usage on the Fedify application server correlating with inbound ActivityPub activity spikes; exhaustion of outbound HTTP connection pool slots (GitHub Advisory).

Upgrade Fedify to one of the patched versions based on your current release branch: 1.9.6, 1.10.5, 2.0.8, or 2.1.1. The patches enforce a maximum HTTP redirect count, prevent revisiting the same URL within a redirect chain, and persist negative public key cache entries for failed remote key fetches to reduce repeated retries. As a network-level workaround prior to patching, implement rate limiting on outbound HTTP requests from the application server and consider blocking or monitoring connections to unknown external hosts. No configuration-only workaround within Fedify itself is available for unpatched versions (GitHub Advisory, Release 1.9.6, Release 2.1.1).

The vulnerability was originally surfaced by a Ghost ActivityPub user reporting the issue directly to the Ghost team, who then investigated further and submitted the report to the Fedify project, crediting @wrathsec (Abhinav Jaswal) as the discoverer (GitHub Advisory). The Fedify maintainers responded promptly, releasing patched versions across all supported branches on March 27, 2026, prior to the CVE's public disclosure on April 6, 2026. No significant broader media coverage or notable social media discussion has been identified beyond the GitHub advisory and standard CVE tracking sites.