CVE-2024-52791 Overview
Matrix Media Repo (MMR) is a multi-homeserver media repository for the Matrix protocol. The application makes outbound requests to other servers during normal operation and parses JSON responses returned by those remote hosts. A remote server can return very large JSON payloads that MMR parses without bounds, leading to memory exhaustion on the MMR host. The flaw is tracked as [CWE-789: Memory Allocation with Excessive Size Value]. The vendor fixed the issue in MMR v1.3.8. The vulnerability is network-reachable, requires no authentication, and impacts availability of the affected service.
Critical Impact
A remote, unauthenticated attacker controlling any federated resource can exhaust MMR process memory and cause a denial of service across the media repository.
Affected Products
- t2bot matrix-media-repo prior to v1.3.8
- Matrix homeserver deployments using MMR as a federated media backend
- Multi-homeserver Matrix installations relying on MMR for media proxying
Discovery Timeline
- 2025-01-16 - CVE-2024-52791 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-52791
Vulnerability Analysis
MMR acts as a media proxy and federation participant within the Matrix ecosystem. During normal operation it issues HTTP requests to remote homeservers and content owners, then deserializes the JSON responses to extract media metadata and federation directives. The parser does not enforce an upper bound on the size of the JSON document it accepts from a remote peer. A malicious or compromised remote host can therefore return a multi-gigabyte JSON response, forcing MMR to allocate proportional buffers in memory. Sustained or parallel requests amplify the impact, exhausting host RAM and causing the MMR process to be killed by the operating system or to enter a degraded state. This is a classic resource exhaustion pattern aligned with [CWE-789].
Root Cause
The root cause is unbounded memory allocation during JSON parsing of responses fetched from untrusted remote servers. MMR trusts the size of inbound responses without enforcing a streaming limit, maximum content length, or parser-level cap. Because federated Matrix traffic is, by design, sourced from third-party servers outside the operator's control, any peer can supply the oversized payload.
Attack Vector
An attacker hosts a server reachable by MMR or causes MMR to fetch a resource under their control, for example by uploading or referencing media that triggers a federated lookup. When MMR issues the outbound request, the attacker returns a JSON response that is intentionally large or expanded with deeply nested structures. MMR parses the response, allocating memory until the process or host is exhausted. No authentication is required, and exploitation depends only on MMR being willing to contact an attacker-influenced host.
No public proof-of-concept code is available. See the GitHub Security Advisory GHSA-gp86-q8hg-fpxj for vendor-provided technical detail.
Detection Methods for CVE-2024-52791
Indicators of Compromise
- MMR processes terminated by the Linux OOM killer or restarted by a supervisor due to memory pressure.
- Sudden spikes in resident memory consumption by the matrix-media-repo process correlated with outbound federation requests.
- Outbound HTTP responses to MMR with abnormally large Content-Length values or chunked responses exceeding expected media metadata sizes.
Detection Strategies
- Monitor MMR process memory using cgroup or container metrics and alert when usage approaches configured limits.
- Inspect MMR access and federation logs for repeated requests to the same remote host preceding memory spikes.
- Use a forward proxy in front of MMR to log and cap response sizes for outbound fetches, flagging responses that exceed a sane media metadata threshold.
Monitoring Recommendations
- Track process_resident_memory_bytes and OOM events for MMR via Prometheus, systemd, or container orchestration metrics.
- Alert on MMR process restarts and correlate timestamps with federation peer activity.
- Forward MMR and reverse proxy logs to a centralized analytics platform for retention and correlation across multiple MMR instances.
How to Mitigate CVE-2024-52791
Immediate Actions Required
- Upgrade MMR to v1.3.8 or later, which contains the vendor fix. See the GitHub Release v1.3.8.
- Inventory all MMR deployments, including ancillary worker processes, and confirm each instance is running a patched build.
- Apply memory limits via systemd, Docker, or Kubernetes to contain any residual exhaustion attempts.
Patch Information
The vendor released the fix in matrix-media-repo v1.3.8. Full details are documented in the GitHub Security Advisory GHSA-gp86-q8hg-fpxj. Operators should upgrade rather than rely on workarounds.
Workarounds
- Configure a forward proxy to block MMR requests to unsafe or attacker-controlled hosts and to cap response sizes from upstream servers.
- Run MMR with explicit memory limits and automatic restart on failure using systemd MemoryMax= or container resource constraints.
- Run multiple MMR processes concurrently behind a load balancer so a single process restart does not interrupt service for all users.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
