TL;DR: Mastodon's server-side request forgery protection blocklist omitted the IPv4-compatible IPv6 address range (::/96). An attacker controlling a DNS record pointing to an address like ::127.0.0.1 could trick any Mastodon instance into fetching internal services, including loopback interfaces and cloud metadata endpoints. Fixed in versions 4.4.21, 4.5.14, and 4.6.4.

The Fix

Three patched releases close the gap. If you run Mastodon 4.4.x, upgrade to 4.4.21. On 4.5.x, move to 4.5.14. On 4.6.x, update to 4.6.4. The 4.7.0-alpha line gets 4.7.0-alpha.2. Each release adds the IPv4-compatible IPv6 address range (::0.0.0.0/96) to the private address blocklist that Mastodon checks before performing outbound HTTP requests.

The patch is a one-line addition to the PrivateAddressCheck module: IPv4-compatible IPv6 addresses (addresses in the ::A.B.C.D format defined in RFC 4291) are now treated the same as their IPv4 counterparts. Before the fix, Mastodon resolved a hostname to its IPs, checked each against a list of blocked private ranges, and rejected the request if any matched. The blocklist covered IPv4 private space and IPv6 ULA/link-local ranges but left a hole for the deprecated IPv4-compatible IPv6 format.

How the Bypass Works

Mastodon federates over ActivityPub. Every instance fetches remote content from other instances and processes user-submitted links for link previews, media cards, and OpenGraph metadata. Each outbound fetch passes through Mastodon's SSRF guard, which resolves the target hostname and checks the resulting IP against a blocklist of private and loopback ranges.

The blocklist contained IPv4 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16) and IPv6 non-routable ranges (fc00::/7, fe80::/10, ::1). What it missed: IPv4-compatible IPv6 addresses. These are addresses in the format ::A.B.C.D, where the first 96 bits are zero and the last 32 bits encode an IPv4 address. The format was defined in RFC 4291 but deprecated in favor of IPv4-mapped IPv6 addresses (::ffff:A.B.C.D).

An attacker who controls DNS for any domain can publish an AAAA record resolving to ::127.0.0.1 or ::169.254.169.254. When Mastodon fetches a URL on that domain (for a link preview, for media retrieval, for any ActivityPub interaction), the SSRF check sees the IPv6 address, fails to recognize it as private, and allows the request. The operating system then connects to the embedded IPv4 address.

The practical targets are the same as any SSRF attack:

• Cloud metadata services at 169.254.169.254 on AWS, GCP, and Azure instances
• Internal admin panels and APIs bound to localhost
• Services on the private network behind the instance
• Redis, PostgreSQL, or other databases reachable from the Mastodon host

There is a caveat. IPv4-compatible IPv6 addresses are an obsolete mechanism. Modern Linux kernels route ::A.B.C.D traffic through the IPv4 stack only if the net.ipv6.bindv6only sysctl is set to 0 and the kernel explicitly supports the format. Many distributions disable this by default. The advisory rates the severity as Moderate for this reason. Instances running on older systems or custom configurations that enable IPv4-compatible IPv6 support are at higher risk.

Who Is Affected

Mastodon is the largest federated social network server, with roughly 10,300 active instances serving 18.2 million registered accounts and 1.4 million monthly active users as of mid-2026. Every instance running an unpatched version is affected, though exploitability depends on OS-level IPv6 configuration.

Affected versions:

• All 4.4.x releases prior to 4.4.21
• All 4.5.x releases (including alpha) prior to 4.5.14
• All 4.6.x releases (including alpha) prior to 4.6.4
• 4.7.0-alpha.1

Self-hosted instances on cloud providers (AWS, GCP, Azure, DigitalOcean) face the highest exposure because cloud metadata endpoints are reachable from the instance and can leak IAM credentials and instance configuration.

What Mastodon Is

Mastodon is a free, open-source social network server written in Ruby on Rails. Instead of a single central platform, Mastodon uses the ActivityPub protocol to federate across thousands of independent instances. Users on one instance can follow and interact with users on any other instance. Each instance operator controls hosting, moderation policy, and configuration. The project has 50,200 stars on GitHub and is maintained by the Mastodon gGmbH non-profit.

Because federation requires every instance to fetch content from remote servers continuously, the SSRF surface is fundamental to the architecture. Mastodon cannot avoid making outbound requests to user-controlled URLs. The IP blocklist is the primary defense, and this CVE shows why blocklist completeness matters.

Upgrading

For Docker-based deployments, pull the matching tag:

docker pull tootsuite/mastodon:v4.4.21
# or
docker pull tootsuite/mastodon:v4.5.14
# or  
docker pull tootsuite/mastodon:v4.6.4

For source installs, checkout the release tag and rebuild:

git fetch && git checkout v4.4.21
bundle install
yarn install
RAILS_ENV=production bundle exec rails db:migrate
RAILS_ENV=production bundle exec assets:precompile
systemctl restart mastodon-web mastodon-sidekiq mastodon-streaming

If you cannot upgrade immediately, set ALLOWED_PRIVATE_ADDRESSES to an empty string (the default) and verify that your instance's host OS does not route IPv4-compatible IPv6 traffic. On Linux, check with:

sysctl net.ipv6.bindv6only
# If 0, IPv4-compatible IPv6 may be routed through the IPv4 stack

Why This Matters

This is the second SSRF bypass CVE for Mastodon in 2026. CVE-2026-47389, disclosed earlier this summer, found that PrivateAddressCheck returned false for IPv4-mapped IPv6 addresses on Ruby versions prior to 3.4, allowing the same class of attack through ::ffff:A.B.C.D format addresses. That CVE was fixed in 4.5.10, 4.4.17, and 4.3.23.

The pattern is clear: IP address validation across multiple representations is hard, and each format introduces a new bypass path. Mastodon's blocklist approach (enumerate every private range across every address representation) is fragile by design. A positive validation model (only allow public, routable addresses) would be more robust but harder to implement for federated systems that must reach arbitrary remote servers.

No known exploitation in the wild has been reported for this specific CVE. The advisory was published July 27, 2026, with patches available the same day.

References

• GitHub Security Advisory GHSA-vwhj-3g83-v276
• Mastodon 4.4.21 release
• Mastodon 4.5.14 release
• Mastodon 4.6.4 release
• CWE-918: Server-Side Request Forgery
• CVE-2026-72916 record