CVE-2026-50131: Server-Side Request Forgery Validation Bypass in Fedify

The vulnerability is an unauthenticated Server-Side Request Forgery (SSRF) in Fedify, an ActivityPub server framework written in TypeScript. Fedify allows developers to build federated server applications that exchange ActivityPub documents and media. Because federated interactions necessitate fetching resources from external servers, the system is exposed to external URLs supplied by users or peer federated servers.

To prevent SSRF, Fedify utilizes a validation mechanism named validatePublicUrl which verifies whether an IP address is a public, routable internet address before attempting a network connection. An analysis of the validation engine revealed that the framework failed to classify multiple special-use, reserved, and non-routable IP address ranges as private. Consequently, remote unauthenticated attackers can craft requests containing restricted IP addresses to bypass the validation boundaries and target internal network services.

The vulnerability is tracked as CVE-2026-50131 and has been assigned a CVSS v3.1 base score of 8.6, representing high severity. The underlying flaw resides within the custom IP validation utility functions distributed in the @fedify/fedify framework and its dependency utility package @fedify/vocab-runtime.

The root cause of CVE-2026-50131 lies in the flawed design and implementation of the IP address classification logic. Fedify attempted to determine whether an IP address is "public" by excluding a limited blocklist of known private subnets rather than adopting a robust, comprehensive CIDR range checking approach. The original validation logic in isValidPublicIPv4Address only evaluated basic subnets from RFC 1918, local loopback ranges, and standard link-local allocations.

Specifically, the validator parsed the target IP address string using a manual split on the dot separator and extracted the first and second octets as integers. It then checked if the first octet matched 10, 127, or 0. If so, or if the prefix fell inside 172.16.0.0/12 or 192.168.0.0/16, the address was marked invalid. This logic completely ignored Carrier-Grade NAT (CGNAT) address ranges defined by RFC 6598 (100.64.0.0/10), benchmarking ranges from RFC 2544 (198.18.0.0/15), documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24), multicast ranges (224.0.0.0/4), and future-use reserved ranges (240.0.0.0/4).

Furthermore, the validation of IPv6 addresses in isValidPublicIPv6Address was similarly incomplete. It expanded the IPv6 address and filtered out standard Unique Local Addresses (ULA) and link-local ranges but was incapable of parsing and resolving transition and tunneling mechanisms. For example, NAT64 networks use the prefix 64:ff9b::/96 to translate IPv4 packets into IPv6. Because the validator lacked translation mapping checks, an attacker could supply an IPv6-wrapped private IPv4 address (such as 64:ff9b::127.0.0.1), which would successfully bypass the validation routine and subsequently map to local loopback within a dual-stack configuration.

An examination of the source code before and after the application of the patch highlights the exact architectural shift from naive string parsing to rigorous bitwise CIDR validation. The original vulnerable function in packages/vocab-runtime/src/url.ts is shown below:

// VULNERABLE CODE PATH
export function isValidPublicIPv4Address(address: string): boolean {
  const parts = address.split(".");
  const first = parseInt(parts[0]);
  if (first === 0 || first === 10 || first === 127) return false;
  const second = parseInt(parts[1]);
  if (first === 169 && second === 254) return false;
  if (first === 172 && second >= 16 && second <= 31) return false;
  if (first === 192 && second === 168) return false;
  return true;
}

The vulnerability is fixed in commit c5b46f82668edbc3ee17a466e259627d846da498. The developer rewrote the validation framework to use standard CIDR boundaries. The implementation parses the input address safely, validating that each octet consists strictly of decimal digits via the regex /^\d+$/ to block any radix-obfuscation vectors (such as octal or hex formats). The patched structure establishes an array of restricted ranges defined with accurate CIDR masks:

// PATCHED IMPLEMENTATION (Excerpt from url.ts)
const nonPublicIPv4Prefixes = [
  ipv4Prefix("0.0.0.0/8", "RFC 6890"),
  ipv4Prefix("10.0.0.0/8", "RFC 1918"),
  ipv4Prefix("100.64.0.0/10", "RFC 6598"), // Added CGNAT
  ipv4Prefix("127.0.0.0/8", "RFC 1122"),
  ipv4Prefix("169.254.0.0/16", "RFC 3927"),
  ipv4Prefix("172.16.0.0/12", "RFC 1918"),
  ipv4Prefix("192.0.0.0/24", "RFC 6890"),   // Added Protocol Assignments
  ipv4Prefix("192.0.2.0/24", "RFC 5737"),   // Added Documentation range
  ipv4Prefix("192.88.99.0/24", "RFC 7526"),  // Added 6to4 Anycast
  ipv4Prefix("192.168.0.0/16", "RFC 1918"),
  ipv4Prefix("198.18.0.0/15", "RFC 2544"),  // Added Benchmarking
  ipv4Prefix("198.51.100.0/24", "RFC 5737"), // Added Documentation range
  ipv4Prefix("203.0.113.0/24", "RFC 5737"),  // Added Documentation range
  ipv4Prefix("224.0.0.0/4", "RFC 5771"),     // Added Multicast
  ipv4Prefix("240.0.0.0/4", "RFC 1112"),     // Added Reserved
];

The updated validation engine iterates over the defined CIDR prefixes, performs bitwise operations on the numeric representation of the parsed IP address, and immediately rejects the target if any match occurs. Similarly, for IPv6, the code was updated to map well-known transition ranges back to their embedded IPv4 representations, which are then routed back into the secure IPv4 checker.

Exploitation of CVE-2026-50131 requires sending a crafted ActivityPub fetch request containing a reference to a target host that resolves to one of the non-blocked, private IP addresses. For example, if an internal API panel or metadata service is hosted on the Carrier-Grade NAT block 100.64.0.10, an attacker cannot query it directly from the internet. However, they can instruct the vulnerable Fedify instance to request a remote resource from that IP address.

To coordinate the attack, the adversary registers a DNS domain (e.g., trigger.internal.attacker-dns.com) and configures the domain's A record to point directly to 100.64.0.10. Next, the attacker submits an ActivityPub action (such as subscribing to an actor profile at https://trigger.internal.attacker-dns.com/actor) via the public endpoint of the vulnerable Fedify server. The server receives the URL, resolves the domain name using DNS, and obtains the IP address 100.64.0.10.

The server then executes validatePublicUrl() on the resolved address. Because the validation blocklist before version 1.9.12/2.0.19 did not contain 100.64.0.0/10, the check succeeds and evaluates the IP as public. The server proceeds to dispatch an HTTP GET request to http://100.64.0.10/actor. The attacker receives the internal server's response content via the application's outbound rendering pipeline, effectively executing an unauthenticated SSRF.

The impact of successful exploitation is substantial, particularly within modern containerized and cloud-native environments. Attackers can leverage the SSRF capability to conduct network port scanning against the internal subnet infrastructure, bypassing firewall perimeters and ingress controls. In doing so, they can map out internal services, databases, cache layers (such as Redis or Memcached), and administrative management consoles that are bound strictly to internal network interfaces.

In cloud environments (such as AWS, Azure, or GCP), modern systems heavily rely on local metadata services for credential management. While typical metadata endpoints (like 169.254.169.254) were theoretically blocked by the original validation logic, the presence of transition mechanisms in dual-stack networks or internal NAT proxies could still expose these services. The ability to query internal HTTP interfaces unauthenticated allows for potential local credential extraction, configuration theft, and further lateral movement within the compromised VPC.

The vulnerability is classified under CWE-918 (Server-Side Request Forgery) as the primary weakness, coupled with CWE-1286 and CWE-1389 due to the underlying parsing weaknesses. Given the lack of required privileges and the network vector, the CVSS base score is calculated at 8.6, reflecting the high potential for internal information disclosure and system manipulation.

The primary remediation path requires immediately updating @fedify/fedify and @fedify/vocab-runtime dependencies to their corresponding patched releases. Multiple release branches have been maintained to facilitate upgrade paths: users on the 1.9.x branch must update to 1.9.12 or higher; users on 1.10.x must update to 1.10.11 or higher; users on 2.0.x must update to 2.0.19 or higher; users on 2.1.x must update to 2.1.15 or higher; and users on 2.2.x must update to 2.2.4 or higher.

In addition to applying software patches, developers must review whether their application is vulnerable to DNS Rebinding. Because the validation of the IP occurs during the hostname resolution phase, it is critical that the actual HTTP socket request binds strictly to the resolved and validated IP, rather than initiating a secondary DNS query during the actual HTTP fetch phase. Implementing a custom agent in the underlying HTTP client library that intercepts DNS resolution and enforces IP-level validation on the target socket connection is the most resilient architectural strategy.

At the network layer, egress filtering should be configured to prevent the application servers from initiating outbound connections to any internal subnet. By employing strict firewall rules or security groups that allow outbound traffic only to established external gateways and blocking all local loopback, CGNAT, and private address blocks, organizations can achieve a robust defense-in-depth posture that mitigates potential validation-bypass vulnerabilities.