CVE-2024-37903 Overview
CVE-2024-37903 is an authorization flaw in Mastodon, the self-hosted federated microblogging platform. Starting in version 2.6.0 and prior to versions 4.1.18 and 4.2.10, an attacker can craft specific ActivityPub activities to extend the audience of a post they do not own. This allows the attacker to deliver another user's post to additional Mastodon accounts on a target server, exposing content not intended for them. The flaw is classified as Missing Authorization [CWE-862]. Mastodon released patches in versions 4.1.18 and 4.2.10.
Critical Impact
Remote unauthenticated attackers can expand the audience of posts they do not own, breaking the confidentiality of private or limited-audience Mastodon statuses.
Affected Products
- Mastodon versions 2.6.0 through 4.1.17
- Mastodon 4.2.0 through 4.2.9
- Self-hosted Mastodon federated server deployments
Discovery Timeline
- 2024-07-05 - CVE-2024-37903 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-37903
Vulnerability Analysis
The vulnerability resides in Mastodon's ActivityPub Create activity handler. When an inbound activity references an existing status by URI, Mastodon previously returned the existing status without verifying that the activity originator owned it. An attacker can craft a Create activity that references a status owned by another account and supply a new audience list. The server then treats the activity as legitimate and delivers the referenced post to the attacker-supplied recipients. This results in unauthorized disclosure of post contents intended for a restricted audience.
Root Cause
The root cause is a missing authorization check [CWE-862] in app/lib/activitypub/activity/create.rb. The find_existing_status method located a status by object_uri or atomUri but never validated that the status belonged to the activity's signing account. The patch adds an ownership check that returns the status only when status.account_id matches @account.id.
Attack Vector
Exploitation is remote and unauthenticated at the network layer. An attacker operating any ActivityPub-capable server federates a crafted Create activity to a target Mastodon instance. The activity references a third-party post URI and lists the attacker's chosen recipients. The target server accepts the activity and fans out the referenced post to the new audience.
def find_existing_status
status = status_from_uri(object_uri)
status ||= Status.find_by(uri: @object['atomUri']) if @object['atomUri'].present?
- status
+ status if status&.account_id == @account.id
end
def process_status_params
Source: Mastodon commit a1c7aae. The patch enforces that the existing status must belong to the account associated with the inbound activity before it is reused.
Detection Methods for CVE-2024-37903
Indicators of Compromise
- Inbound ActivityPub Create activities whose object.id or atomUri references a status not owned by the signing actor.
- Unexpected federation deliveries of existing local statuses to remote accounts that were not in the original audience.
- Sidekiq ActivityPub::ProcessingWorker jobs processing Create activities referencing pre-existing status URIs.
Detection Strategies
- Audit Mastodon application logs for inbound Create activities where the referenced object_uri resolves to a status whose account_id differs from the activity actor.
- Correlate federation queue activity with status visibility changes to identify audience expansions that did not originate from the post author.
- Monitor for repeated requests from a single remote actor referencing many distinct local status URIs.
Monitoring Recommendations
- Forward Mastodon Rails and Sidekiq logs to a centralized logging platform and alert on anomalous federation patterns.
- Track Mastodon release versions across the fleet and flag any instance running a version below 4.1.18 or 4.2.10.
- Review HTTP signature validation logs for actors repeatedly referencing third-party object URIs.
How to Mitigate CVE-2024-37903
Immediate Actions Required
- Upgrade Mastodon to version 4.1.18, 4.2.10, or later on every federated instance under administrative control.
- Identify any Mastodon deployments running versions 2.6.0 through 4.2.9 and prioritize them for patching.
- Review inbound federation logs from the disclosure window for activities that reference statuses not owned by the signing actor.
Patch Information
Mastodon released fixes in v4.1.18 and v4.2.10. The code change is documented in commit a1c7aae and commit d4bf22b. Full details are in the GitHub Security Advisory GHSA-xjvf-fm67-4qc3.
Workarounds
- No official workaround exists; upgrading to a patched release is the only supported remediation.
- Operators may temporarily restrict federation with untrusted instances using domain blocks until patches are applied.
- Limit account creation on remote servers known to send malformed activities while patching is in progress.
# Upgrade a self-hosted Mastodon instance to a patched version
cd /home/mastodon/live
git fetch --tags
git checkout v4.2.10
bundle install
yarn install --frozen-lockfile
RAILS_ENV=production bundle exec rails db:migrate
RAILS_ENV=production bundle exec rails assets:precompile
sudo systemctl restart mastodon-web mastodon-sidekiq mastodon-streaming
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

