CVE-2026-27468: Joinmastodon Mastodon DOS Vulnerability

CVE-2026-27468 Overview

CVE-2026-27468 is an authorization bypass vulnerability in Mastodon, the free, open-source social network server based on ActivityPub. The vulnerability exists in the experimental FASP (Fediverse Auxiliary Service Providers) feature where actions performed by a FASP to subscribe to account/content lifecycle events or to backfill content did not properly verify whether the FASP was actually approved by an administrator.

Critical Impact

Unapproved FASP providers can bypass administrator approval to subscribe to events and request content backfill, leading to information disclosure and potential denial of service through sidekiq worker exhaustion.

Affected Products

• Mastodon versions 4.4.0 through 4.4.13
• Mastodon versions 4.5.0 through 4.5.6
• Servers with EXPERIMENTAL_FEATURES environment variable including fasp

Discovery Timeline

• 2026-02-24 - CVE CVE-2026-27468 published to NVD
• 2026-02-26 - Last updated in NVD database

Technical Details for CVE-2026-27468

Vulnerability Analysis

This vulnerability is classified as CWE-862 (Missing Authorization). The FASP registration system in Mastodon requires manual approval by an administrator before a provider can access server functionality. However, the authorization check in the base controller responsible for handling FASP requests failed to verify whether the provider had been confirmed by an administrator.

The flaw allows an attacker to register as a FASP provider and immediately perform privileged operations without waiting for administrator approval. When exploited once, this results in minor information leakage of publicly available URIs. However, repeated exploitation creates a serious denial of service vector by overwhelming the sidekiq worker responsible for the fasp queue.

This vulnerability only affects Mastodon servers that have explicitly opted in to testing the experimental FASP feature by setting the EXPERIMENTAL_FEATURES environment variable to include fasp.

Root Cause

The root cause lies in the app/controllers/api/fasp/base_controller.rb file where the FASP provider lookup did not filter for confirmed providers. The original code used Fasp::Provider.find(keyid) which would return any provider matching the key ID, regardless of their confirmation status. This missing authorization check allowed unconfirmed providers to authenticate and perform actions reserved for approved FASPs.

Attack Vector

The attack is network-based and requires no prior authentication or user interaction. An attacker can:

1. Register as a FASP provider on a target Mastodon instance
2. Without waiting for administrator approval, immediately begin making API requests using their provider credentials
3. Subscribe to account and content lifecycle events to receive notifications about server activity
4. Request content backfill operations to retrieve existing content
5. Repeatedly issue these requests to exhaust the sidekiq fasp queue workers, causing denial of service

# Vulnerable code - app/controllers/api/fasp/base_controller.rb
     provider = nil
 
     Linzer.verify!(request.rack_request, no_older_than: 5.minutes) do |keyid|
-      provider = Fasp::Provider.find(keyid)
+      provider = Fasp::Provider.confirmed.find(keyid)
       Linzer.new_ed25519_public_key(provider.provider_public_key_pem, keyid)
     end

Source: GitHub Mastodon Commit Update

# Additional fix - app/models/fasp/provider.rb
   before_create :create_keypair
   after_commit :update_remote_capabilities
 
+  scope :confirmed, -> { where(confirmed: true) }
   scope :with_capability, lambda { |capability_name|
     where('fasp_providers.capabilities @> ?::jsonb', "[{\"id\": \"#{capability_name}\", \"enabled\": true}]")
   }

Source: GitHub Mastodon Commit Update

Detection Methods for CVE-2026-27468

Indicators of Compromise

• Unusual FASP provider registrations that have not been approved but are actively making API requests
• Unexpected entries in the fasp_providers table with confirmed: false that show recent activity
• Abnormal growth in sidekiq fasp queue depth or worker utilization
• Log entries showing FASP API requests from providers not in the approved provider list

Detection Strategies

• Monitor the Mastodon database for FASP providers with confirmed: false that have associated subscription or backfill activity
• Implement alerting on sidekiq queue depth for the fasp queue to detect potential DoS attempts
• Review application logs for FASP API endpoint access patterns and correlate with provider approval status
• Audit fasp_providers table regularly for unexpected or unapproved entries

Monitoring Recommendations

• Configure log aggregation to capture all FASP-related API requests including provider key IDs
• Set up performance monitoring on sidekiq workers to detect queue exhaustion attacks
• Enable database query logging for the fasp_providers table to track unauthorized access attempts
• Implement network traffic analysis to identify unusual patterns of FASP API requests

How to Mitigate CVE-2026-27468

Immediate Actions Required

• Upgrade Mastodon to version 4.4.14 or 4.5.7 immediately if using the experimental FASP feature
• Review the fasp_providers table for any unconfirmed providers and assess their activity
• Temporarily disable the FASP feature by removing fasp from the EXPERIMENTAL_FEATURES environment variable until patched
• Monitor sidekiq queues for any signs of ongoing exploitation

Patch Information

The fix is included in Mastodon releases 4.4.14 and 4.5.7. The patch adds a confirmed scope to the Fasp::Provider model and modifies the base controller to only authenticate providers that have been explicitly approved by an administrator. Administrators actively testing the experimental FASP feature should update their systems immediately.

For detailed patch information, see the GitHub Security Advisory GHSA-qgmm-vr4c-ggjg.

Workarounds

• Remove fasp from the EXPERIMENTAL_FEATURES environment variable to completely disable the experimental FASP feature
• Manually review and delete any unconfirmed FASP providers from the database
• Implement network-level access controls to restrict FASP API endpoints to known, trusted IP addresses
• Consider rate limiting on FASP API endpoints at the reverse proxy level

# Configuration example - Disable FASP feature temporarily
# In your Mastodon .env.production file, ensure EXPERIMENTAL_FEATURES does not include 'fasp'

# Before (vulnerable if fasp is included):
# EXPERIMENTAL_FEATURES=fasp,other_feature

# After (safe - remove fasp):
EXPERIMENTAL_FEATURES=other_feature

# Or remove the variable entirely if fasp was the only experimental feature:
# (comment out or delete the line)
# EXPERIMENTAL_FEATURES=

# Restart Mastodon services after making changes
sudo systemctl restart mastodon-web mastodon-sidekiq mastodon-streaming