CVE-2024-52791
📋 TL;DR
Matrix Media Repo (MMR) versions before 1.3.8 are vulnerable to memory exhaustion attacks when processing malicious JSON responses from external servers. Attackers can send specially crafted JSON payloads that cause MMR to consume excessive memory, potentially leading to denial of service. This affects all MMR deployments that process media from untrusted Matrix servers.
💻 Affected Systems
- Matrix Media Repo (MMR)
📦 What is this software?
⚠️ Risk & Real-World Impact
Worst Case
Complete service outage due to memory exhaustion, causing MMR to crash and disrupting media services for all users across the connected Matrix homeservers.
Likely Case
Intermittent service degradation or temporary unavailability as MMR processes restart after hitting memory limits, affecting media uploads/downloads for some users.
If Mitigated
Minimal impact with proper memory limits and monitoring, where affected processes restart automatically without significant user disruption.
🎯 Exploit Status
Exploitation requires controlling a Matrix server that MMR communicates with, or ability to send malicious JSON responses to MMR requests.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 1.3.8
Vendor Advisory: https://github.com/t2bot/matrix-media-repo/security/advisories/GHSA-gp86-q8hg-fpxj
Restart Required: Yes
Instructions:
1. Backup current configuration. 2. Stop MMR service. 3. Download v1.3.8 from GitHub releases. 4. Replace existing binary with new version. 5. Restart MMR service. 6. Verify service is running correctly.
🔧 Temporary Workarounds
Configure Forward Proxy
allSet up a forward proxy to block requests to untrusted or potentially malicious hosts
# Configure proxy settings in MMR config.yaml
proxy: "http://your-proxy:port"
Set Memory Limits
linuxConfigure process memory limits and auto-restart policies
# Using systemd (Linux)
MemoryMax=2G
Restart=on-failure
RestartSec=5
🧯 If You Can't Patch
- Deploy multiple MMR instances behind a load balancer to ensure service continuity during restarts
- Implement aggressive rate limiting and request filtering for external server communications
🔍 How to Verify
Check if Vulnerable:
Check MMR version: if version is less than 1.3.8, system is vulnerableCheck Version:
./media_repo --versionVerify Fix Applied:
Confirm MMR version is 1.3.8 or higher and monitor memory usage during normal operation📡 Detection & Monitoring
Log Indicators:
- Memory allocation errors
- Process crashes/restarts
- High memory usage spikes
- JSON parsing errors
Network Indicators:
- Unusually large JSON responses from external servers
- Repeated requests to same external endpoints
SIEM Query:
process.name="media_repo" AND (memory.usage>90% OR event.type="crash")