☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]

CVE-2024-37903

CVE-2024-37903 Improper Access Control in Mastodon
📅 PUBLISHED: 2024-07-05 17:24 UTC 🔄 UPDATED: 2026-09-23 20:15 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: LIKELY — 2 independent sources confirm fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.53%
👁️
0.53% probability
13.1× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Patch available — upgrade to latest release
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
8.2
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2024-37903 is a critical authorization bypass vulnerability in Mastodon, a self-hosted, federated microblogging platform. The flaw affects versions starting from 2.6.0 up to (but not including) 4.1.18 and 4.2.10. By crafting specific ActivityPub activities, an attacker can extend the audience of a post they do not own to other Mastodon users on a target server, thereby gaining unauthorized access to the contents of a post not intended for them. This vulnerability has a CVSS score of 8.2 (High) and is classified under CWE-284 (Improper Access Control). The attack vector is network-based, requires low complexity, and no privileges or user interaction, making it highly exploitable. No public proof-of-concept (PoC) or exploit code has been released at this time.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Supply Chain & Package Security

Mastodon is a Ruby on Rails application distributed via GitHub and Docker images. The vulnerability exists in the core ActivityPub processing logic, which is part of the main application codebase. Organizations using Mastodon should verify their deployment version and apply the patch immediately. There are no known compromised dependencies or malicious packages associated with this CVE.

CVSS Breakdown & Threat Level

  • CVSS Score: 8.2 (High)
  • Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
  • Attack Vector (AV): Network (N) – The vulnerability can be exploited remotely over the network.
  • Attack Complexity (AC): Low (L) – No special conditions or complex attack sequences are required.
  • Privileges Required (PR): None (N) – The attacker does not need any authentication or privileges.
  • User Interaction (UI): None (N) – The victim does not need to perform any action.
  • Scope (S): Unchanged (U) – The vulnerable component and the impacted component are the same.
  • Confidentiality (C): High (H) – Complete loss of confidentiality; all post data can be accessed.
  • Integrity (I): None (N) – No impact on data integrity.
  • Availability (A): None (N) – No impact on system availability.

Threat Level: High. The vulnerability allows unauthorized access to private or limited-audience posts, which can lead to data breaches and privacy violations.

Deep Dive & Mechanics

The vulnerability resides in Mastodon's ActivityPub implementation, specifically in how the platform processes and validates the audience of incoming activities. ActivityPub is a decentralized social networking protocol that Mastodon uses to federate with other instances.

When a user creates a post with a limited audience (e.g., followers-only or specific mentions), Mastodon attaches an audience property to the ActivityPub object. The vulnerable code fails to properly validate that the actor sending the activity has the authority to extend the audience of a post they do not own.

An attacker can craft a malicious ActivityPub activity that:

  1. References a post (object) that belongs to another user.
  2. Includes additional to or cc fields that specify target users on a different Mastodon server.
  3. The target server's ActivityPub processor incorrectly accepts the modified audience, delivering the post to users who were not originally intended to see it.

The core issue is a missing authorization check: the server does not verify that the sender of the activity is the owner of the post or has been granted permission to modify its audience. This allows an attacker to effectively "re-share" any post to any user on a federated server.

Vulnerable vs. Patched Code

The vulnerable code is located in the ActivityPub processing pipeline, likely in the ActivityPub::Activity or ActivityPub::Activity::Create classes. The exact patch diff is not publicly available, but the fix involves adding an authorization check to ensure that only the post owner can modify the audience.

Vulnerable Code (Conceptual):

# app/lib/activitypub/activity/create.rb
def process_audience
  # No check on who is sending the activity
  @object.to = @json['to']
  @object.cc = @json['cc']
  @object.save!
end

Patched Code (Conceptual):

# app/lib/activitypub/activity/create.rb
def process_audience
  # Verify that the sender is the owner of the object
  return unless @account == @object.account
  @object.to = @json['to']
  @object.cc = @json['cc']
  @object.save!
end

The patch ensures that only the account that owns the post can modify its audience. This prevents attackers from extending the audience of posts they do not own.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

  • A Mastodon instance running a vulnerable version (>= 2.6.0, < 4.1.18 or < 4.2.10).
  • An attacker-controlled Mastodon account on a different instance.
  • Knowledge of the target post's URI (e.g., https://target.instance/users/victim/statuses/12345).

Exploitation Steps:

  1. Identify a target post with a limited audience (e.g., followers-only).
  2. Craft a malicious ActivityPub activity that includes the target post as the object and adds the attacker's target users to the to or cc fields.
  3. Send the activity to the target server's inbox endpoint (/inbox).
  4. The target server processes the activity and delivers the post to the unintended users.

Example Malicious Activity (JSON):

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Create",
  "actor": "https://attacker.instance/users/attacker",
  "object": {
    "id": "https://target.instance/users/victim/statuses/12345",
    "type": "Note",
    "content": "This is a private post",
    "to": ["https://target.instance/users/attacker_target"],
    "cc": []
  },
  "to": ["https://target.instance/users/attacker_target"],
  "cc": []
}

Note: No public exploit code is available. The above is a conceptual representation.

Blue Team (Detection & Defense)

Detection:

  • Monitor ActivityPub inbox endpoints for activities where the actor does not match the object's owner.
  • Look for activities that modify the to or cc fields of existing posts.
  • Alert on any delivery of posts to users who were not in the original audience.

Defense:

  • Immediately upgrade to Mastodon 4.1.18 or 4.2.10.
  • If patching is not possible, implement a Web Application Firewall (WAF) rule to block suspicious ActivityPub activities.
  • Restrict federation to trusted instances only.

Indicators of Compromise (IOCs)

  • Network IOCs:
    • Unusual ActivityPub activities where the actor is different from the object's owner.
    • Activities with to or cc fields that include users not in the original audience.
  • Log IOCs:
    • Log entries showing delivery of posts to unexpected users.
    • Errors in ActivityPub processing related to audience validation.
  • File IOCs:
    • Modified database entries in the statuses table where visibility or mentions have been altered.

Detection Engineering

YARA Rule

rule CVE_2024_37903_Mastodon_Audience_Bypass {
    meta:
        description = "Detects malicious ActivityPub activities attempting to bypass audience restrictions"
        author = "Valters IT"
        date = "2024-07-01"
        reference = "CVE-2024-37903"
    strings:
        $activity_type = "Create" ascii wide nocase
        $object_field = "\"object\"" ascii wide
        $to_field = "\"to\"" ascii wide
        $cc_field = "\"cc\"" ascii wide
        $actor_field = "\"actor\"" ascii wide
    condition:
        all of them and
        # of ($to_field) > 1 or # of ($cc_field) > 1
}

Sigma Rule

title: CVE-2024-37903 - Mastodon Audience Bypass Detection
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects suspicious ActivityPub activities that may indicate exploitation of CVE-2024-37903
author: Valters IT
date: 2024/07/01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-37903
logsource:
    category: application
    product: mastodon
detection:
    selection:
        event: "activitypub_inbox"
        actor|not_equals: object_owner
    condition: selection
falsepositives:
    - Legitimate re-sharing by authorized users
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-37903 - Mastodon Audience Bypass Attempt"; flow:to_server; content:"/inbox"; http_uri; content:"\"actor\""; http_client_body; content:"\"object\""; http_client_body; content:"\"to\""; http_client_body; distance:0; within:500; content:"\"cc\""; http_client_body; distance:0; within:500; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

  1. Upgrade Mastodon to version 4.1.18 or 4.2.10 (or later).
  2. If immediate upgrade is not possible, restrict federation to trusted instances only.
  3. Monitor ActivityPub logs for suspicious activities.

Long-term Measures:

  • Implement strict input validation for all ActivityPub activities.
  • Regularly review and update federation policies.
  • Conduct security audits of the ActivityPub processing code.

Workarounds:

  • Disable federation temporarily if the vulnerability is actively exploited.
  • Use a reverse proxy to filter malicious ActivityPub payloads.

Valters IT

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-37903/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.