CVE-2026-47389: Mastodon SSRF Vulnerability

CVE-2026-47389 Overview

CVE-2026-47389 is a Server-Side Request Forgery (SSRF) vulnerability in Mastodon, the open-source ActivityPub-based social network server. The flaw affects deployments running Ruby versions older than 3.4, where PrivateAddressCheck.private_address? incorrectly returns false for IPv4-mapped IPv6 addresses in the ::ffff:a.b.c.d format. Attackers who control DNS for an attacker-owned domain can publish an AAAA record pointing to a mapped private address, causing Mastodon to open outbound TCP connections to internal resources. Affected versions include all releases prior to 4.5.10, 4.4.17, and 4.3.23. The vulnerability is tracked under [CWE-184] (Incomplete List of Disallowed Inputs).

Critical Impact
An attacker can coerce Mastodon to connect to loopback (127.0.0.1), RFC1918 private networks, and cloud metadata endpoints such as 169.254.169.254, exposing internal services and potentially leaking cloud credentials.

Affected Products

Mastodon versions prior to 4.3.23
Mastodon versions prior to 4.4.17
Mastodon versions prior to 4.5.10 (when running on Ruby older than 3.4)

Discovery Timeline

2026-06-24 - CVE-2026-47389 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-47389

Vulnerability Analysis

The vulnerability resides in Mastodon's outbound HTTP fetch safety check. The PrivateAddressCheck.private_address? method enumerates known private IP ranges to block SSRF attempts. On Ruby versions older than 3.4, the standard library's IP address parsing handles IPv4-mapped IPv6 addresses inconsistently. An address such as ::ffff:127.0.0.1 is not recognized as belonging to the loopback range, so the check returns false and the request proceeds.

Mastodon performs outbound fetches for many activities, including remote profile lookups, link previews, media retrieval, and ActivityPub federation. Each of these flows resolves a remote hostname and connects to the returned address. If the resolver returns an AAAA record containing a mapped address, Mastodon establishes a real TCP connection to the embedded IPv4 destination.

Root Cause

The root cause is an incomplete deny list. The private-address validator does not normalize IPv4-mapped IPv6 addresses to their IPv4 equivalents before comparing against blocked ranges. Depending on the Ruby version, missed ranges include loopback (127.0.0.0/8), RFC1918 networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and link-local space (169.254.0.0/16). This pattern matches [CWE-184], where the validator fails to cover all input representations of the same logical value.

Attack Vector

Exploitation requires no authentication and no user interaction on the Mastodon server. An attacker registers a domain they control and publishes an AAAA DNS record such as evil.example. AAAA ::ffff:169.254.169.254. The attacker then triggers any Mastodon flow that fetches a URL on that hostname, for example by submitting a status containing a link, sending an ActivityPub message, or requesting media. Mastodon resolves the hostname, passes the SSRF check, and connects to the cloud metadata endpoint. On AWS, this can return temporary IAM credentials attached to the instance.

Detection Methods for CVE-2026-47389

Indicators of Compromise

Outbound connections from Mastodon worker processes to 127.0.0.1, RFC1918 ranges, or 169.254.169.254 on non-standard ports
DNS resolutions returning AAAA records in the ::ffff:0:0/96 range for external hostnames referenced by Mastodon
Sidekiq job logs containing fetches to attacker-controlled domains followed by internal-address connection attempts
Unexpected access entries in cloud metadata service logs originating from the Mastodon host

Detection Strategies

Inspect egress traffic from Mastodon application and worker hosts for connections targeting private or link-local destinations
Enable DNS query logging and alert on responses containing IPv4-mapped IPv6 addresses
Review HTTP client logs in the Mastodon application for fetches that resolve to private IP space
Correlate ActivityPub inbound activity with subsequent outbound fetch behavior to identify SSRF probing

Monitoring Recommendations

Apply continuous egress monitoring on Mastodon nodes with deny-by-default rules toward metadata and internal-management ranges
Forward Sidekiq, Rails, and reverse proxy logs to a central SIEM for behavioral analysis
Track the Ruby runtime version on each Mastodon host and alert when a host runs Ruby older than 3.4

How to Mitigate CVE-2026-47389

Immediate Actions Required

Upgrade Mastodon to 4.5.10, 4.4.17, or 4.3.23 depending on the deployed release line
Upgrade the underlying Ruby runtime to 3.4 or later where feasible
Restrict outbound network access from Mastodon hosts to required destinations only
Block access to the cloud metadata endpoint 169.254.169.254 from the Mastodon application using IMDSv2, host firewall, or VPC controls

Patch Information

The Mastodon maintainers fixed the issue by normalizing IPv4-mapped IPv6 addresses before evaluating the private-address deny list. Full details are available in the Mastodon GitHub Security Advisory GHSA-xx55-4rrg-8xg6.

Workarounds

Enforce IMDSv2 on AWS instances hosting Mastodon to require session-token requests that SSRF cannot forge
Configure egress firewall rules denying traffic from Mastodon hosts to loopback, RFC1918, and link-local ranges
Route Mastodon outbound HTTP through an egress proxy that performs its own address validation before connecting

bash

# Example iptables egress restriction for a Mastodon host
iptables -A OUTPUT -d 127.0.0.0/8 -m owner --uid-owner mastodon -j REJECT
iptables -A OUTPUT -d 169.254.0.0/16 -m owner --uid-owner mastodon -j REJECT
iptables -A OUTPUT -d 10.0.0.0/8 -m owner --uid-owner mastodon -j REJECT
iptables -A OUTPUT -d 172.16.0.0/12 -m owner --uid-owner mastodon -j REJECT
iptables -A OUTPUT -d 192.168.0.0/16 -m owner --uid-owner mastodon -j REJECT