CVE-2026-50131: Fedify IPv4 SSRF Validation Bypass—HIGH Severity

Technical summary

The vulnerability stems from an incomplete implementation of `isValidPublicIPv4Address()` in the `validatePublicUrl()` function, introduced in Fedify 0.11.2 as a mitigation for a prior SSRF issue (GHSA-p9cg-vqcc-grcx). The function blocks well-known private ranges (10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.168.0.0/16) but fails to reject special-use IPv4 ranges including multicast addresses, benchmarking ranges, and carrier-grade NAT blocks. This omission allows attackers to specify URLs with these unblocked reserved ranges as fetch destinations, bypassing the SSRF defense and enabling access to internal services. The affected versions are 0.11.2 through 1.9.11, 1.10.0 through 1.10.10, 2.0.0 through 2.0.18, 2.1.0 through 2.1.14, and all versions before 2.2.4 in the 2.2 series.

Business impact

Organizations deploying Fedify in federated social media or communication platforms face heightened risk of internal network reconnaissance and data exfiltration. An unauthenticated attacker could probe internal infrastructure, access metadata services (such as cloud provider credential endpoints), or interact with internal APIs by embedding specially-crafted IPv4 addresses in ActivityPub payloads. This could lead to credential compromise, lateral movement, or unauthorized access to backend services. The impact is particularly severe if Fedify instances are internet-facing and trusted to consume remote content.

Affected systems

Fedify versions 0.11.2 and later (prior to the patched versions) are affected. Specifically: versions 0.11.2–1.9.11, 1.10.0–1.10.10, 2.0.0–2.0.18, 2.1.0–2.1.14, and 2.2.0–2.2.3. Patched versions are 1.9.12, 1.10.11, 2.0.19, 2.1.15, and 2.2.4 and later. Any deployment of Fedify in these unpatched version ranges that processes remote ActivityPub documents or media with user-controlled or untrusted source URLs is vulnerable.

Exploitability

Exploitation requires no authentication, user interaction, or complex setup. An attacker can craft an ActivityPub document with a URL targeting one of the unblocked reserved IPv4 ranges (e.g., 240.0.0.0/4, 224.0.0.0/4, or 192.0.2.0/24) and transmit it to a Fedify application. The library will fetch the URL, allowing the attacker to enumerate internal services, retrieve metadata, or access local resources. The relatively low attack complexity and broad attack surface (any remote ActivityPub document) make this vulnerability practically exploitable in real-world scenarios.

Remediation

Update Fedify to a patched version immediately: 1.9.12 or later (for 1.9.x), 1.10.11 or later (for 1.10.x), 2.0.19 or later (for 2.0.x), 2.1.15 or later (for 2.1.x), or 2.2.4 or later (for 2.2.x and above). The patches correct the IPv4 validation logic to comprehensively block all reserved, special-use, and non-routable ranges as defined by IANA. Verify compatibility with your application before deployment, particularly if you maintain custom integrations with Fedify's fetch or validation hooks.

Patch guidance

Prioritize upgrading to the latest stable version in your release branch (2.2.4+ recommended for new deployments, or the corresponding patch for your current version). Test the update in a staging environment to confirm no breaking changes to ActivityPub document parsing or media fetching behavior. If you cannot upgrade immediately, consider implementing a network-level firewall rule to block outbound connections to reserved IPv4 ranges from your Fedify application server as a temporary mitigation, though this is not a substitute for patching.

Detection guidance

Monitor Fedify application logs for unusual outbound fetch attempts targeting IPv4 ranges outside normal CDN and public content provider ranges (240.0.0.0/4, 224.0.0.0/4, 192.0.0.0/24, 198.18.0.0/15, etc.). Deploy network telemetry to flag connections from your Fedify servers to RFC 1918 or reserved address space. Review ActivityPub documents received from external sources for URLs with anomalous IP addresses. Consider enabling debug logging in Fedify's fetch layer to capture rejected and accepted requests for post-incident analysis.

Why prioritize this

This vulnerability merits immediate attention due to its CVSS 8.6 (HIGH) severity, zero authentication requirements, and direct implications for data confidentiality and integrity. The SSRF class of vulnerability is consistently leveraged by attackers for reconnaissance and lateral movement. The fact that it represents a bypass of a previously-deployed security control indicates sophisticated attacker interest and potential pre-existing exploitation against unpatched systems. Organizations should treat this as a critical patch in their risk-management workflow.

Risk score, explained

The CVSS 3.1 score of 8.6 reflects a network-accessible vulnerability (AV:N) with low attack complexity (AC:L) requiring no privileges or user interaction (PR:N, UI:N). The scope is unchanged (S:U), but the confidentiality impact is rated high (C:H) due to potential information disclosure from internal services, with lesser but present integrity and availability impacts (I:L, A:L) from potential service interference or manipulation. This combination yields a HIGH severity classification appropriate to the SSRF bypass scenario.

Frequently asked questions