The Mastodon Flaw That Turns the Server Into a Stepping Stone: Which Versions Are Safe

The server software of Mastodon, a decentralized social network used as an alternative to X (formerly Twitter), contains a vulnerability (a software flaw) that lets an attacker abuse the server itself as a stepping stone to make unauthorized connections from outside. It is tracked as CVE-2026-47389, with a severity of 8.6 out of 10 (High). Affected are servers running Mastodon 4.5.9 and earlier, 4.4.16 and earlier, or 4.3.22 and earlier on Ruby older than 3.4, and the flaw itself is fixed in 4.5.10 / 4.4.17 / 4.3.23. Since then, however, more vulnerabilities have surfaced in Mastodon, so as of 2026-07-24, whether you are standing up a new instance (server) or running one, the safest choice is to move to the latest 4.6.3 / 4.5.13 / 4.4.20 line.

Because an attacker can simply craft the DNS settings of their own domain to reach the server's internal services or cloud management information (credentials), this is a high-priority flaw for anyone administering an instance. It was published as a GitHub security advisory on June 24, 2026. About one month on, as of 2026-07-24, there are still no reports of it being used in real attacks, as noted below.

What Mastodon is, and what SSRF is

Mastodon is a decentralized social network where thousands of servers (instances) around the world work together, rather than being run wholesale by a single company. A user creates an account on some instance and can interact with people on other instances too. Many instances are run in Japan as well, holding a steady user base as an alternative to X. The server software is published as open source, so anyone can stand up their own instance.

This flaw is the kind called SSRF (Server-Side Request Forgery). It refers to an attack that makes the server itself connect, behind the scenes, to internal services or cloud management addresses that should not be reachable directly from outside. Because Mastodon accesses external URLs to build link previews and federate with other instances, if an attacker steers where it connects, the internal secrets can come within reach.

Who targets it, what they do, and what happens

This attack can be carried out by an outside third party who prepares a single domain and can freely set its DNS (the table mapping domain names to addresses). They do not even need a Mastodon account; merely owning one domain meets the conditions.

What the attacker does is register a crafted address in DNS, make the Mastodon server access that domain, and have it connect behind the scenes to internal or cloud management addresses, then read the response. Targets include the server's internal admin screens (127.0.0.1), internal networks, and "metadata" management addresses in the cloud (AWS's 169.254.169.254, Alibaba Cloud's 100.100.100.200, and so on).

It is especially serious when Mastodon runs in the cloud. Cloud metadata can contain the credentials (the keys for operating the cloud) assigned to that server, and stealing them can lead to taking over the entire cloud account. For an instance administrator this means losing control of the whole infrastructure, and for the instance's users it ties directly to the risk of a personal-data leak.

Vulnerabilities that begin to be used in real attacks can be added to the U.S. agency CISA's "list of vulnerabilities under active attack." As of 2026-07-24, CVE-2026-47389 is not on that list, and no report of it being actually exploited has been confirmed. That said, the mechanism of the attack is public, so continuing to run an affected version is not safe. We maintain a Japanese-language overview in our CISA KEV Dashboard (Japanese edition).

What the vulnerability is

Mastodon blocks connections to dangerous destinations (127.0.0.1 and internal/cloud management addresses) with a denylist in advance. The problem here is that a way of writing an address that slips past that check remained. An earlier flaw of the same kind (GHSA-xfrj-c749-jxxq) had already been patched, but that fix was incomplete, so a different way of writing the address could slip through again.

CVE-2026-47389: crafting DNS to connect to internal/cloud addresses behind the scenes (CVSS 8.6)

According to the published information, the root cause is that Ruby (the programming language Mastodon uses) before version 3.4 does not correctly handle "an IPv4 address expressed in IPv6 form (the ::ffff:a.b.c.d format)." The attacker registers an AAAA record (an IPv6 DNS setting) on their domain that points, in this format, to a dangerous address.

When Mastodon accesses that domain, a mismatch occurs where the denylist check is passed but the actual destination is an internal or cloud management address, so the server connects to a place it should never reach. The reachable range depends on the Ruby version. The fixed versions (4.5.10 / 4.4.17 / 4.3.23) added the slipping address format to the denylist. In addition, upgrading to Ruby 3.4 or later resolves the root cause.

A quick check of whether your instance is affected

Affected are the versions in the table below when run on Ruby older than 3.4. You can check the Mastodon version in the admin panel. This flaw itself is closed in each line's fixed version (4.5.10 / 4.4.17 / 4.3.23), but other vulnerabilities (below) have also been found in Mastodon since disclosure, so the safest destination is the latest version.

Since CVE-2026-47389 was published, several more vulnerabilities have been fixed in Mastodon in a row. The main ones are a critical flaw in FFmpeg, the video-processing component bundled in the Docker container (CVE-2026-8461, fixed in 4.6.2 / 4.5.13 / 4.4.20); an issue where some fields are left out of the signature check on posts (CVE-2026-50128, fixed in 4.5.11 / 4.4.18); and insufficient certificate verification when talking to an internal user directory over LDAP (GHSA-3rhr-8phh-jm86, fixed in 4.5.12 / 4.4.19). In addition, the 4.6 major line with new features was released in mid-June 2026, and as of 2026-07-24 the latest is 4.6.3 / 4.5.13 / 4.4.20. For these reasons, rather than stopping at 4.5.10 / 4.4.17 / 4.3.23 (which only close CVE-2026-47389), it is safest to go all the way to the latest.

Note that the 4.3 line does not appear in the latest release set as of 2026-07-24 (4.6.3 / 4.5.13 / 4.4.20), so it may have fallen out of scope for further security updates (no official end-of-support announcement has been confirmed). If you run the 4.3 line, update to 4.3.23 to hold the line for now, and plan a migration to a maintained line (4.4 or later).

A user who merely has an account on Mastodon cannot fix this flaw themselves. You will need to check whether your instance's administrator has updated, or wait for the operator to act. Note that larger instances run in the cloud tend to have a bigger impact.

What to do now

If you run an instance, the top priority is to update Mastodon to the latest version (the 4.6.3 / 4.5.13 / 4.4.20 line). Get the latest version matching the line you use from the official releases. For CVE-2026-47389 alone, 4.5.10 / 4.4.17 / 4.3.23 close it, but other vulnerabilities have been fixed since disclosure, so moving all the way to the latest is more reliable. In addition, updating the server's Ruby to 3.4 or later resolves the root cause of this issue itself.

If you run in the cloud, combining settings that tighten access to metadata (for example, requiring the newer "IMDSv2" method on AWS) limits the damage even if the check is bypassed. If you suspect it may have already been exploited, rotate the cloud credentials (keys) after updating and check the logs for any suspicious access. This is also a good time to review whether internal admin screens (such as Sidekiq) are placed where they cannot be reached from outside.

Summary

Mastodon's CVE-2026-47389 is an SSRF vulnerability that exploits a flaw in address handling before Ruby 3.4, letting an attacker abuse the server as a stepping stone—merely by crafting DNS—to connect behind the scenes to internal or cloud management information. Its severity is CVSS 8.6, it affects 4.5.9 and earlier, 4.4.16 and earlier, and 4.3.22 and earlier, and the flaw itself is fixed in 4.5.10 / 4.4.17 / 4.3.23. As of 2026-07-24, it is not on CISA's "list of vulnerabilities under active attack," and no report of actual exploitation has been confirmed.

Especially on cloud instances, there is a risk of cloud keys being stolen and the whole account taken over, so the risk of leaving it unpatched is not small. Since this vulnerability was disclosed, Mastodon has fixed further flaws in a row (such as CVE-2026-8461 in a bundled FFmpeg component), and the 4.6 major line has also shipped. If you run an instance, first check your version and, if it is old, update to the latest 4.6.3 / 4.5.13 / 4.4.20 line. Updating Ruby is also worth considering.

References

• ▸NVD - CVE-2026-47389 (Mastodon SSRF)
• ▸GitHub Security Advisory - GHSA-xx55-4rrg-8xg6
• ▸GitHub - mastodon/mastodon releases (latest: 4.6.3 / 4.5.13 / 4.4.20)
• ▸Help Net Security - Mastodon 4.6 released
• ▸SentinelOne - CVE-2026-50128 (a related flaw fixed after disclosure)
• ▸Mastodon official site (service overview)
• ▸Ruby official site (upgrading to 3.4+)
• ▸AWS - configuring the instance metadata service (IMDSv2)