SSRF Flaw in Mastodon Lets the Server Be Abused to Reach Cloud Secrets (CVE-2026-47389) — Update Now
Mastodon's server software has an SSRF flaw that lets an attacker abuse the server itself as a stepping stone to make unauthorized connections from outside. CVE-2026-47389, severity CVSS 8.6. By merely crafting DNS, an attacker can reach internal services or cloud management info (keys) and steal credentials. Versions 4.5.9 / 4.4.16 / 4.3.22 and earlier are affected; operators should update to 4.5.10 / 4.4.17 / 4.3.23.
Makoto Horikawa
Backend Engineer / AWS / Django
Mastodon's server software has an SSRF flaw that lets an attacker abuse the server itself as a stepping stone to make unauthorized connections from outside. CVE-2026-47389, severity CVSS 8.6. By merely crafting DNS, an attacker can reach internal services or cloud management info (keys) and steal credentials. Versions 4.5.9 / 4.4.16 / 4.3.22 and earlier are affected; operators should update to 4.5.10 / 4.4.17 / 4.3.23.
The server software of Mastodon, a decentralized social network used as an alternative to X (formerly Twitter), has been found to contain 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. It was reported by GitHub and disclosed on June 24, 2026. The fixes are included in 4.5.10 / 4.4.17 / 4.3.23. 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), administrators running an instance (server) need to update right away.
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." 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.
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. Update to the fixed version that matches the release line you use.
| Your Mastodon | State | What to do |
|---|---|---|
| 4.5.9 and earlier (4.5 line) | Affected | Update to 4.5.10 |
| 4.4.16 and earlier (4.4 line) | Affected | Update to 4.4.17 |
| 4.3.22 and earlier (4.3 line) | Affected | Update to 4.3.23 |
| The fixed versions or later | Fixed | No action needed |
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 4.5.10 / 4.4.17 / 4.3.23 or later. Get the fixed version matching the line you use from the official releases. 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 it is fixed in 4.5.10 / 4.4.17 / 4.3.23.
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. If you run an instance, first check your version and, if it is old, update now. Updating Ruby is also worth considering. If new vulnerabilities concerning Mastodon emerge, we will track them by adding to this article.