CVE-2024-47824

Executive Summary

CVE-2024-47824 is a high-severity vulnerability in the matrix-react-sdk, the official React-based SDK for building Matrix chat/VOIP clients. The flaw allows a malicious or compromised homeserver to steal historical message encryption keys when a user invites another user to a room. By injecting a malicious device controlled by the homeserver, an attacker can intercept the shared keys, decrypt past conversations, and compromise the confidentiality of all prior communications in that room.

The vulnerability affects all versions from 3.18.0 up to (but not including) 3.102.0. The fix, released in version 3.102.0, disables the sharing of historical message keys on invite by removing the vulnerable code paths. No public proof-of-concept (PoC) or exploit code has been released, but the attack vector is straightforward for a malicious homeserver operator.

Supply Chain & Package Security

This vulnerability resides in the matrix-react-sdk npm package. Organizations using Element Web, Element Desktop, or any custom Matrix client built on this SDK are at risk. The attack is supply-chain-adjacent: a compromised homeserver (which is a server-side component) can exploit client-side behavior to exfiltrate keys. While the SDK itself is not malicious, the trust model of Matrix assumes homeservers are honest; this CVE breaks that assumption.

CVSS Breakdown & Threat Level

CVSS Score: 6.1 (Medium)
Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:N

• Attack Vector (AV): Network – The malicious homeserver communicates over the network.
• Attack Complexity (AC): Low – No special conditions required; the homeserver simply injects a device.
• Privileges Required (PR): Low – The attacker must control or compromise a homeserver (or be a malicious admin).
• User Interaction (UI): Required – The victim user must invite another user to a room.
• Scope (S): Changed – The impact extends beyond the vulnerable component (the SDK) to the confidentiality of room messages.
• Confidentiality (C): High – All historical messages in the room are exposed.
• Integrity (I): None – No modification of data.
• Availability (A): None – No denial of service.

Threat Level: High for organizations using Matrix for sensitive communications. The attack is silent and leaves no trace on the client.

Deep Dive & Mechanics

Matrix uses end-to-end encryption (Olm/Megolm) to protect message content. When a user is invited to a room, the client must share the current room key (Megolm session) so the new member can decrypt messages sent after joining. However, prior to version 3.102.0, the SDK also shared historical message keys (past Megolm sessions) with the new device.

The attack flow:

1. Attacker controls a homeserver (or compromises one).
2. Victim user A is in a room with sensitive historical messages.
3. Victim user A invites user B (who may be a legitimate user or a dummy account).
4. The homeserver, during the invite process, injects a malicious device belonging to the attacker into the key-sharing protocol.
5. The SDK, believing the device is legitimate, shares all historical room keys with that device.
6. The attacker now possesses the keys to decrypt every past message in the room.

The vulnerability is in the MatrixClient class, specifically in the shareHistory or sendSharedHistory methods (exact function names may vary). The patched version removes these calls entirely.

Vulnerable vs. Patched Code

Vulnerable (simplified pseudocode):

// In matrix-react-sdk < 3.102.0
function onInvite(room, invitee) {
    // ... other invite logic ...
    if (shouldShareHistory(room)) {
        // This call shares ALL past Megolm sessions
        client.shareHistoryKeys(room, invitee.devices);
    }
}

Patched (version 3.102.0):

// In matrix-react-sdk >= 3.102.0
function onInvite(room, invitee) {
    // ... other invite logic ...
    // The shareHistoryKeys call is completely removed.
    // Only current session keys are shared via normal protocol.
}

The fix is a simple removal of the shareHistoryKeys call. No workarounds exist; upgrading is mandatory.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• A Matrix homeserver you control (e.g., Synapse).
• A Matrix client using matrix-react-sdk < 3.102.0 (e.g., Element Web 1.11.60).
• A target room with historical messages.

Steps:

1. Set up a malicious homeserver (or modify an existing one) to intercept invite events.
2. Create a dummy user account on your homeserver.
3. As the victim, invite the dummy user to a room containing sensitive historical messages.
4. On your homeserver, modify the /invite response to include an additional device ID that you control.
5. The victim’s client will share all historical keys with that device.
6. Use the obtained keys to decrypt the room’s message history.

Note: No public exploit code exists. This is a conceptual attack.

Blue Team (Detection & Defense)

Detection:

• Monitor for unusual device additions during invite events.
• Alert on any m.room_key or m.forwarded_room_key events that contain an unusually large number of keys (indicating history sharing).
• Use network monitoring to detect unexpected key-sharing traffic.

Defense:

• Immediately upgrade to matrix-react-sdk 3.102.0 or later.
• If upgrade is not possible, disable automatic key sharing by patching the client code (not recommended long-term).
• Rotate all room keys after upgrading to ensure any leaked keys are invalidated.

Indicators of Compromise (IOCs)

• Network: Unexpected m.room_key events with algorithm: "m.megolm.v1.aes-sha2" and a session_id that does not match the current room session.
• Client Logs: Entries containing shareHistoryKeys or sendSharedHistory in the debug logs.
• Device List: A device appearing in the room’s device list that was not part of the original invite.
• Homeserver Logs: Anomalous /keys/claim or /keys/upload requests from a device that should not exist.

Detection Engineering

YARA Rule

rule CVE_2024_47824_Matrix_History_Key_Share {
    meta:
        description = "Detects matrix-react-sdk code that shares historical message keys on invite"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-47824"
        hash = "sha256:placeholder"
    strings:
        $s1 = "shareHistoryKeys" ascii wide nocase
        $s2 = "sendSharedHistory" ascii wide nocase
        $s3 = "m.room_key" ascii wide nocase
        $s4 = "m.forwarded_room_key" ascii wide nocase
    condition:
        any of ($s1, $s2) or (all of ($s3, $s4))
}

Sigma Rule

title: Matrix Historical Key Sharing on Invite
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects network traffic indicating sharing of historical room keys in Matrix protocol
author: Valters IT
date: 2025-04-10
logsource:
    category: network_connection
    product: zeek
detection:
    selection:
        event_type: "m.room_key"
        algorithm: "m.megolm.v1.aes-sha2"
        session_id|re: "^[a-f0-9]{32}$"
    condition: selection
falsepositives:
    - Legitimate key sharing for current session (not historical)
level: high

Suricata Rule

alert tcp any any -> any 443 (msg:"CVE-2024-47824 Matrix Historical Key Share"; flow:to_server,established; content:"m.room_key"; content:"m.megolm.v1.aes-sha2"; content:"session_id"; distance:0; within:100; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

• Upgrade matrix-react-sdk to version 3.102.0 or later.
• For Element Web/Desktop users: update to the latest version that includes the patched SDK.

Short-term:

• If upgrade is not possible, manually patch the client code to remove the shareHistoryKeys call (not recommended for production).
• Rotate all room keys in sensitive rooms after upgrading.

Long-term:

• Implement homeserver trust verification (e.g., using Matrix’s cross-signing and device verification).
• Monitor for any unexpected key-sharing events in your Matrix deployment.

Valters IT Signature:
This report was generated by Valters IT DevSecOps AI. All information is provided for authorized security testing and defense purposes only.