Which versions of Mastodon are affected by CVE-2026-46348?

Mastodon instances running versions before 4.5.10, 4.4.17, or 4.3.23 contain a Server-Side Request Forgery vulnerability (CVE-2026-46348) that enables attackers to access internal backend systems and…. A patch is available.

How to fix or mitigate CVE-2026-46348?

Within 24 hours: Identify all Mastodon instances in your infrastructure and document current versions. Within 7 days: Upgrade to Mastodon 4.5.10, 4.4.17, or 4.3.23 depending on your current branch. Within 30 days: Review server logs for suspicious internal HTTP requests to loopback addresses and audit backend systems for any unauthorized access attempts.

Mastodon CVE-2026-46348

Q: What is the CVSS score of CVE-2026-46348?

CVE-2026-46348 has a CVSS 4.0 base score of 8.7 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.3%.

EUVD-2026-39053 HIGH

Server-Side Request Forgery (SSRF) (CWE-918)

2026-06-24 GitHub_M

SSRF Mastodon

8.7

CVSS 4.0 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

8.7 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

7.2 HIGH

Network-reachable SSRF with low complexity and no auth/UI; scope changes to backend loopback services with limited read/write of internal resources, so S:C and C:L/I:L.

3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Jun 24, 2026 - 21:02 EUVD

Analysis Generated

Jun 24, 2026 - 20:22 vuln.today

DescriptionCVE.org

Mastodon is a free, open-source social network server based on ActivityPub. Prior to 4.5.10, 4.4.17, and 4.3.23, the list of disallowed IP address ranges was lacking an IP address range that can be used to reach local IP addresses. An attacker can use an IP address in the affected range to make Mastodon perform HTTP requests against loopback interfaces, potentially allowing access to otherwise private resources and services. This vulnerability is fixed in 4.5.10, 4.4.17, and 4.3.23.

AnalysisAI

Server-Side Request Forgery in Mastodon before 4.5.10, 4.4.17, and 4.3.23 lets attackers coerce the server into issuing HTTP requests to loopback interfaces, reaching private resources and internal services that should be unreachable from the public internet. The flaw stems from an incomplete IP-range blocklist that omitted a range capable of resolving to local addresses. No public exploit identified at time of analysis; the upstream advisory (GHSA-crr4-7rm4-8gpw) accompanies the fixed releases.

Technical ContextAI

Mastodon is an ActivityPub-based federated social server (Ruby on Rails) that routinely fetches remote URLs for link previews, media, remote actor/profile resolution, and oEmbed data. To prevent SSRF, it maintains a denylist of disallowed IP ranges so outbound fetches cannot target internal/loopback addresses. This vulnerability is a classic CWE-918 (Server-Side Request Forgery): the denylist was missing at least one IP range that can still be routed to local IP addresses (e.g., alternate loopback notations or a range that maps to 127.0.0.0/8-equivalent destinations), so an attacker-supplied address in that gap bypasses the filter and causes Mastodon to connect to services bound on localhost. The affected CPE is cpe:2.3:a:mastodon:mastodon, all versions prior to the three fixed branches.

RemediationAI

Upgrade to a fixed release on your branch: Vendor-released patch 4.5.10, 4.4.17, or 4.3.23 - apply whichever matches your deployed major version (per GHSA-crr4-7rm4-8gpw at https://github.com/mastodon/mastodon/security/advisories/GHSA-crr4-7rm4-8gpw). Because the root cause is an incomplete outbound IP denylist, the only complete fix is the code update; there is no configuration toggle that fully replicates it. As compensating controls until patching, enforce egress filtering at the network/host firewall so the Mastodon worker and web processes cannot connect to 127.0.0.0/8 and other loopback/link-local/private ranges (side effect: ensure legitimate internal service dependencies like the database, Redis, and Elasticsearch are reached over interfaces you explicitly allow, or they will break), and avoid binding sensitive administrative services to localhost on the same host that runs Mastodon's outbound fetchers. Routing outbound media/preview fetches through a forward proxy that re-validates destination IPs can further blunt the bypass.