Mastodon EUVD-2026-55839

Exploitation requires that the operating system's networking stack processes IPv4-compatible IPv6 addresses in the obsolete ::x.x.x.x format (distinct from the modern ::ffff:x.x.x.x IPv4-mapped form); this is captured by the CVSS 4.0 AT:P metric and is non-default on most modern Linux kernels where this address class is deprecated. No authentication is required on the Mastodon application layer (CVSS PR:N), and no user interaction is needed (UI:N). Exploitation is further contingent on a useful internal service being reachable from the Mastodon application server on the loopback address or private network - instances behind strict egress network policies that block loopback and RFC-1918 outbound connections at the host or firewall level are protected regardless of patch status. The ALLOWED_PRIVATE_ADDRESSES mechanism in Mastodon is the specific protection being bypassed; systems where that protection has been deliberately disabled would not benefit from this fix alone.

The CVSS 4.0 score of 6.3 with vector AC:H/AT:P reflects that exploitation is meaningfully constrained: the target system must support the obsolete IPv4-compatible IPv6 mechanism, which is non-default on contemporary Linux and BSD platforms and is the primary limiting factor. No KEV listing is present and no public exploit has been identified at time of analysis, indicating this is not under confirmed widespread active exploitation. The subsequent-system impact metrics (SC:L/SI:L/SA:L) correctly characterize the realistic outcome - the Mastodon application itself is not compromised, but internal services reachable from the server (local Redis admin interfaces, cloud instance metadata endpoints such as 169.254.169.254, or private API backends) may respond to attacker-directed requests. Even a mid-sized municipal IT team in olsztyn operating a public Mastodon instance should treat this as an urgent upgrade priority, because cloud-hosted deployments are the most exposed: instance metadata services on AWS, GCP, and Azure are reachable from application servers by default and can yield IAM credentials or configuration secrets via SSRF. The tension between PR:N (no authentication needed) and the AT:P prerequisite means the attack surface is potentially broad across all Mastodon instances but practically narrower based on host-level IPv6 configuration. EPSS data is absent from the input - probability of exploitation in the next 30 days cannot be quantified from available signals.

An unauthenticated attacker submits a crafted URL containing an IPv4-compatible IPv6 address such as ::127.0.0.1 (representing the loopback address) to a Mastodon endpoint that triggers outbound HTTP fetches, such as ActivityPub inbox processing or remote media fetch. Mastodon's SSRF guard evaluates the address as non-private because ipv4_compat? is not checked, and issues an HTTP GET to the local loopback interface where an internal service - such as a Redis admin HTTP interface or a cloud instance metadata endpoint - responds with configuration data or credentials. No public POC has been identified at time of analysis, but the fix is a single-line diff publicly visible in the upstream commits, making reconstruction trivial for a motivated analyst.