CVE-2024-36403: T2bot Matrix-media-repo DOS Vulnerability

CVE-2024-36403 Overview

Matrix Media Repo (MMR) is a configurable multi-homeserver media repository for the Matrix protocol. Versions before 1.3.5 contain an unbounded resource consumption flaw [CWE-770] that allows unauthenticated attackers to trigger downloads of large remote media files into the cache. Instances using a file-backed store or self-hosted S3 backend face disk fill attacks leading to denial of service. Deployments using cloud-based S3 storage face inflated service costs instead of outages. The vendor t2bot released version 1.3.5 with a default-on leaky bucket rate limit to mitigate the issue.

Critical Impact

Unauthenticated remote attackers can exhaust disk storage or generate significant cloud storage costs, blocking authenticated users from uploading new media.

Affected Products

• t2bot matrix-media-repo versions prior to 1.3.5
• MMR deployments using file-backed storage
• MMR deployments using self-hosted S3-compatible storage

Discovery Timeline

• 2025-01-16 - CVE-2024-36403 published to NVD
• 2025-08-20 - Last updated in NVD database

Technical Details for CVE-2024-36403

Vulnerability Analysis

The vulnerability stems from missing rate limiting on remote media retrieval endpoints. MMR caches remote media files when clients request them, including requests from unauthenticated users querying through federation. An attacker can repeatedly request large remote media files, forcing MMR to download and persist them in the configured backend storage. The flaw is categorized under CWE-770 (Allocation of Resources Without Limits or Throttling).

The network-based attack vector requires no privileges or user interaction. The impact depends on the storage backend configuration. File-backed and self-hosted S3 deployments suffer disk exhaustion. Cloud-hosted S3 deployments incur unbounded storage and bandwidth charges. Either outcome disrupts legitimate use, as authenticated users cannot upload new media once storage fills.

Root Cause

MMR lacked a throttling mechanism for media fetch operations from unauthenticated clients. The repository accepted repeated requests for remote media without enforcing per-IP or global limits on bytes downloaded. Cached files persisted without enforcement of cumulative size limits relative to attacker behavior.

Attack Vector

An unauthenticated attacker sends crafted requests to the MMR endpoint that triggers retrieval of remote media. Each request causes MMR to fetch the referenced media from a remote homeserver and cache it locally. By referencing many large files or repeating requests, the attacker drives sustained download activity. The exploitation requires only network reachability to the MMR instance. Refer to the GitHub Security Advisory GHSA-vc2m-hw89-qjxf for vendor technical details.

Detection Methods for CVE-2024-36403

Indicators of Compromise

• Rapid growth in MMR cache directory size or S3 bucket usage without corresponding legitimate user activity.
• High volume of unauthenticated media fetch requests originating from a small set of source IP addresses.
• Repeated requests referencing remote media identifiers from a wide range of foreign homeservers.
• Sustained outbound bandwidth from the MMR host to federated Matrix homeservers.

Detection Strategies

• Monitor MMR access logs for anomalous spikes in /_matrix/media/ download endpoints from unauthenticated sources.
• Track storage backend capacity over short intervals and alert on rapid consumption.
• Correlate reverse proxy logs with MMR fetch activity to identify abusive client IPs.

Monitoring Recommendations

• Deploy disk and S3 bucket utilization alerts with thresholds tuned to normal growth baselines.
• Capture and retain reverse proxy logs that include the X-Forwarded-For header for forensic review.
• Establish billing alerts on cloud storage accounts to detect cost-based exploitation early.

How to Mitigate CVE-2024-36403

Immediate Actions Required

• Upgrade MMR to version 1.3.5 or later to enable the default leaky bucket rate limit.
• Configure the reverse proxy to populate the X-Forwarded-For header so the rate limiter applies to the real client IP.
• Reduce the maximum allowed file size in MMR configuration until patching is complete.
• Apply strict rate limits at the reverse proxy or web application firewall for media fetch endpoints.

Patch Information

The vendor t2bot released MMR 1.3.5 introducing a default-on leaky bucket rate limit that caps the volume of data an unauthenticated user can request. The fix does not fully eliminate the attack but constrains its impact. Operators must ensure the reverse proxy forwards client IP addresses for the rate limit to function correctly. See the GitHub Security Advisory GHSA-vc2m-hw89-qjxf for release details.

Workarounds

• Lower the uploads.maxBytes configuration to reduce the size of any single cached file.
• Enforce restrictive rate limits at an upstream reverse proxy such as NGINX or HAProxy on /_matrix/media/ paths.
• Restrict federation to a trusted set of homeservers where operationally feasible.
• Provision storage quotas at the filesystem or S3 bucket level to bound worst-case consumption.

# Configuration example
# NGINX rate limiting for MMR media endpoints and X-Forwarded-For passthrough
limit_req_zone $binary_remote_addr zone=mmr_media:10m rate=5r/s;

location /_matrix/media/ {
    limit_req zone=mmr_media burst=10 nodelay;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_pass http://mmr_backend;
}