CVE-2026-72916

Executive Summary

CVE-2026-72916 is a server-side request forgery (SSRF) vulnerability in Mastodon, a free, open-source ActivityPub-based social network server. The flaw exists in the private-address validation logic — specifically in PrivateAddressCheck.private_address? located in app/lib/private_address_check.rb — which fails to recognize IPv4-compatible IPv6 addresses, allowing an attacker to bypass the ALLOWED_PRIVATE_ADDRESSES protection. All Mastodon versions prior to 4.4.21, 4.5.14, 4.6.4, and 4.7.0-beta.1 are affected; exploitation is conditional on the host system still supporting the obsolete IPv4-compatible IPv6 mechanism, and the practical impact is unauthorized HTTP requests to loopback interfaces and potentially other private network resources.

Technical Analysis

Mastodon routinely performs outbound HTTP requests as part of its normal operation — any feature that accepts attacker-influenced URLs and triggers a server-side fetch passes through a private-address screening function. That function, PrivateAddressCheck.private_address?, is designed to prevent the server from being coerced into contacting loopback or private network ranges, mitigating classic SSRF abuse. The check correctly normalizes IPv4-mapped IPv6 addresses (the ::ffff:a.b.c.d form), translating them back to their IPv4 representation before comparison against the configured private ranges. However, the implementation does not apply the same normalization to IPv4-compatible IPv6 addresses, which are expressed as ::a.b.c.d and represent an IPv4 address embedded in the obsolete ::/96 IPv6 prefix. The description explicitly notes that the code does not call IPAddr#ipv4_compat? to detect this alternate form.

The omission is significant because ::127.0.0.1 is a syntactically valid IPv6 literal that, on systems supporting IPv4-compatible IPv6, is routed to the IPv4 loopback address 127.0.0.1. Similarly, ::10.0.0.1, ::172.16.0.1, or ::192.168.1.1 can resolve to private IPv4 endpoints. When an attacker supplies a URL containing such an IPv4-compatible literal, the ALLOWED_PRIVATE_ADDRESSES gate sees an address it does not recognize as private, permits the request, and Mastodon subsequently issues an HTTP request that the host network stack directs to a loopback or private interface. Modern operating systems deprecated IPv4-compatible IPv6 in RFC 4291 (superseding the 1996 standard), and most current distributions disable it by default; this environmental dependency significantly narrows the real-world exploitability of the flaw but does not eliminate it, particularly on older or minimally hardened hosts.

Since the vulnerability exists in the shared outbound-request validation path, any input that ultimately results in a server-side URL fetch is part of the attack surface. The CNA/NVD description does not enumerate specific endpoints or features, so the affected surface should be treated as the entire set of Mastodon URL-handling and federation features that respect the private-address check. Technical detail beyond the described check is not available in the advisory; the vulnerability class is a canonical CWE-918 SSRF enabled by an incomplete canonicalization — one representation of a private address is normalized while a second, equivalent representation is not.

Exploitation Scenarios

No public PoC or exploit code is available, and no Nuclei template or exploit listing was identified in the intelligence data. The following attack chain is therefore inferred from the vulnerability class and the described flaw, not from observed exploit activity.

1. Reconnaissance / target identification. An attacker identifies self-hosted Mastodon instances via banner grabbing and search engine/SHODAN dorks (e.g., http.title:"Mastodon") and fingerprints the version by querying public API and server metadata. Instances running versions before 4.4.21, 4.5.14, 4.6.4, or 4.7.0-beta.1 are candidate victims.

2. Trigger selection. The attacker locates a Mastodon feature that accepts a URL and causes the server to make an outbound HTTP request through the code path guarded by PrivateAddressCheck.private_address?. The NVD description does not identify a specific feature; typical candidates in this class of software include federated content retrieval and URL preview/metadata fetching functionality.

3. Payload / execution. The attacker submits a URL whose host portion is an IPv4-compatible IPv6 literal embedding a private IPv4 address — for example, the IPv4-compatible form of loopback (::127.0.0.1) or of a private-range address such as ::10.x.x.x, ::172.16.x.x, or ::192.168.x.x. Because the vulnerable private_address? check does not recognize this representation, the URL passes validation and the outbound HTTP request is issued. The kernel routes the request to the embedded IPv4 destination only if the host supports the obsolete IPv4-compatible IPv6 mechanism — a condition the attacker may probe via differential behavior or by targeting known end-of-life or minimally patched server distributions.

4. Post-exploitation impact. The HTTP request reaches services bound to loopback or to the private network. The attacker can read responses (where the fetch response is reflected back, e.g., in previews or error messages), access internal administration interfaces, read local service banners, attempt to reach container/cloud metadata endpoints, and potentially pivot against adjacent internal systems. Successful SSRF against loopback services can yield sensitive data, authentication material, or configuration details that lower the barrier for further compromise of the Mastodon host.

Impact Assessment

The primary business impact is confidentiality and integrity exposure of services listening on loopback or internal interfaces of the Mastodon server. An attacker who successfully triggers the flaw can interact with local services that are intentionally not exposed to the internet, including databases, caches, administrative sockets, and internal tooling — the precise target list depends on the instance deployment. In well-segmented environments where the Mastodon host has minimal loopback services, the impact may be limited to internal network reconnaissance and low-value resource access; in poorly segmented deployments, the SSRF can become a foothold for lateral movement. Availability impact is not directly implied by the SSRF class.

No official CVSS score or vector is available (CVSS: N/A), which means risk scoring must rely on compensating context. The EPSS probability is 0.00359 (29.1st percentile), indicating a low modeled likelihood of exploitation in the wild, and the CVE is not listed in the CISA Known Exploited Vulnerabilities catalog. Patch confidence is 2/4 (claimed by a single OSV source, not independently confirmed), so the defender's margin for error is smaller: until the vendor advisory is independently verified, the fixed-version claims should be treated as provisional. Affected systems are all self-hosted Mastodon instances on the affected version lines; hosted/Mastodon-as-a-service users are at the mercy of their provider's upgrade cadence.

Detection Guidance

Detection should focus on the anomalous address form itself: IPv4-compatible IPv6 literals ([::w.x.y.z]) are obsolete (RFC 4291) and should essentially never appear in legitimate outbound or inbound HTTP traffic. Secondary signals include unexpected outbound connections from the Mastodon process to loopback (127.0.0.0/8) or RFC 1918 ranges, and any Ruby/Mastodon process contacting non-standard ports on loopback. The rules below are templates; tune field names to your actual log/ECS mappings.

Sigma Rule

title: Mastodon SSRF via IPv4-Compatible IPv6 Address (CVE-2026-72916)
id: 6c3f2a15-8b7d-4e21-9a44-3d9c1f0b7a22
status: experimental
description: Detects HTTP requests containing IPv4-compatible IPv6 literals that embed private IPv4 addresses, indicating an attempt to bypass Mastodon's ALLOWED_PRIVATE_ADDRESSES check.
logsource:
  category: proxy
  product: http
detection:
  selection_url:
    http.url|contains:
      - "[::127."
      - "[::10."
      - "[::172.16."
      - "[::172.17."
      - "[::172.18."
      - "[::172.19."
      - "[::172.20."
      - "[::172.21."
      - "[::172.22."
      - "[::172.23."
      - "[::172.24."
      - "[::172.25."
      - "[::172.26."
      - "[::172.27."
      - "[::172.28."
      - "[::172.29."
      - "[::172.30."
      - "[::172.31."
      - "[::192.168."
  selection_method:
    http.method:
      - GET
      - POST
      - PUT
  condition: selection_url and selection_method
falsepositives:
  - Extremely low; IPv4-compatible IPv6 is deprecated and should not occur in normal traffic.
level: high

YARA Rule

rule CVE_2026_72916_Mastodon_PrivateAddressCheck_SSRF
{
    meta:
        author = "Valters IT Security Research"
        description = "Detects vulnerable Mastodon private_address_check.rb logic and IPv4-compatible IPv6 SSRF payloads"
        cve = "CVE-2026-72916"
        date = "2026-05-01"
    strings:
        $rb_path = "app/lib/private_address_check.rb"
        $fn_name = "private_address?"
        $ipv4_compat_call = "ipv4_compat?"
        $ipaddr_class = "IPAddr"
        $loopback_literal = /\[::127\./
        $private_literal = /\[::(?:10\.|172\.(?:1[6-9]|2[0-9]|3[01])\.|192\.168\.)/
    condition:
        (uint16be(0) == 0x7F45 or filesize < 10KB) and
        (($rb_path or $fn_name or $ipaddr_class) and ($loopback_literal or $private_literal)) or
        ($ipv4_compat_call and $ipaddr_class and not $fn_name)
}

Suricata IDS Rule

alert http any any -> any any (msg:"MASTODON CVE-2026-72916 SSRF Attempt IPv4-Compatible IPv6 Private Address"; flow:established,to_server; http.uri; content:"[::"; pcre:"/\[\::(?:10\.|127\.|172\.(?:1[6-9]|2[0-9]|3[01])\.|192\.168\.)/i"; classtype:attempted-recon; reference:cve,2026-72916; sid:202672916; rev:1;)

alert ip $HOME_NET any -> 127.0.0.0/8 any (msg:"MASTODON CVE-2026-72916 Outbound Loopback Connection from Mastodon Server"; flow:to_server; classtype:attempted-admin; reference:cve,2026-72916; sid:202672917; rev:1;)

Elastic Detection

network where event.type == "start" and
  (
    cidrMatch(destination.ip, "127.0.0.0/8") or
    cidrMatch(destination.ip, "10.0.0.0/8") or
    cidrMatch(destination.ip, "172.16.0.0/12") or
    cidrMatch(destination.ip, "192.168.0.0/16")
  ) and
  process.name == "ruby" and
  network.protocol == "http"

Splunk SPL Query

(index=proxy OR index=network sourcetype=stream:http)
| where like(url, "%[::127.%")
   OR like(url, "%[::10.%")
   OR like(url, "%[::172.16.%")
   OR like(url, "%[::172.17.%")
   OR like(url, "%[::172.18.%")
   OR like(url, "%[::172.19.%")
   OR like(url, "%[::172.20.%")
   OR like(url, "%[::172.21.%")
   OR like(url, "%[::172.22.%")
   OR like(url, "%[::172.23.%")
   OR like(url, "%[::172.24.%")
   OR like(url, "%[::172.25.%")
   OR like(url, "%[::172.26.%")
   OR like(url, "%[::172.27.%")
   OR like(url, "%[::172.28.%")
   OR like(url, "%[::172.29.%")
   OR like(url, "%[::172.30.%")
   OR like(url, "%[::172.31.%")
   OR like(url, "%[::192.168.%")
| stats count min(_time) max(_time) by src_ip, dest_ip, url
| where count > 0

Wazuh OSSEC Rule

<group name="mastodon,cve-2026-72916,">
  <rule id="100281" level="12">
    <decoded>json</decoded>
    <field name="url" type="pcre2">\[::(?:127|10|172\.(?:1[6-9]|2[0-9]|3[01])|192\.168)\.</field>
    <description>CVE-2026-72916: Mastodon SSRF attempt using IPv4-compatible IPv6 literal with embedded private IPv4 address</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence for this advisory is 2/4 — the fix is claimed by a single OSV source and has not been independently confirmed. Treat the upgrade guidance below as provisional until Mastodon publishes an official security advisory.

1. Immediate mitigations (before patching):

   • Verify whether the host kernel supports IPv4-compatible IPv6. Modern distributions disable it; if the host does not support it, the vulnerable code path is not practically exploitable, but this should be confirmed per host.
   • Apply outbound egress filtering from the Mastodon host: block connections to RFC 1918 and loopback ranges from the Mastodon service account at the firewall/host-network layer where feasible (note that loopback egress may require namespace or proxy isolation rather than a simple firewall rule).
   • Monitor outbound HTTP fetching behavior for anomalies — alert on any outbound request containing an IPv4-compatible IPv6 literal.
   • If the service cannot be patched immediately, consider temporarily disabling or restricting URL-fetching features that accept unauthenticated or federated URL input.

2. Patch/upgrade steps:

   • Upgrade to Mastodon 4.4.21, 4.5.14, 4.6.4, or 4.7.0-beta.1 (depending on the running version line) as soon as the fix is verified. Do not assume the OSV-sourced version claim is accurate until confirmed by the Mastodon project's official advisory or changelog.
   • After patching, inspect app/lib/private_address_check.rb to confirm the IPAddr#ipv4_compat? case is now handled.

3. Long-term hardening:

   • Keep Mastodon instances on a supported release line and subscribe to the upstream security feed so future SSRF-class fixes are applied promptly.
   • Run outbound HTTP fetches through a hardened egress proxy that enforces allow-lists and rejects both RFC 1918 destinations and deprecated IPv6 address forms.
   • Perform periodic security reviews of the app/lib/private_address_check.rb file and any related input-normalization code; canonicalization bugs of this type commonly recur.
   • Maintain network segmentation so that Mastodon servers cannot reach sensitive internal systems beyond the minimal required surface.

References

• NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2026-72916
• OSV vulnerability record: https://osv.dev/vulnerability/CVE-2026-72916
• Mastodon project (source and security advisories): https://github.com/mastodon/mastodon/security
• CISA KEV: CVE-2026-72916 is not listed in the Known Exploited Vulnerabilities catalog as of this report.
• Exploit-in-the-wild evidence: none identified; PoC status unknown, no Nuclei template, no public exploit code, EPSS 0.00359.

No threat actor campaigns have been publicly associated with this CVE at the time of writing.