CVE-2024-53867

Executive Summary

CVE-2024-53867 is a moderate-severity information disclosure vulnerability affecting the Synapse Matrix homeserver, specifically within the Sliding Sync feature. Versions between 1.113.0rc1 and 1.120.0 (inclusive) are vulnerable. An attacker who was previously a member of a room can, after being removed, still receive partial room state changes via the Sliding Sync endpoint. This leaks metadata about room configuration changes (e.g., topic, name, join rules) but does not leak message content. The vulnerability has a CVSS score of 4.3 (Medium) and no known public exploit code. The fix is available in Synapse 1.120.1.

Supply Chain & Package Security

Synapse is a Python-based Matrix homeserver distributed via PyPI (matrix-synapse). Organizations using Synapse should verify their installed version and update to 1.120.1 or later. The vulnerability is patched in the upstream source; no third-party package modifications are required.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
• Base Score: 4.3 (Medium)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: Low (PR:L) – attacker must have been a room member
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: Low (C:L) – partial room state leakage
• Integrity Impact: None (I:N)
• Availability Impact: None (A:N)

Threat Level: Medium. The vulnerability requires prior room membership and only leaks state metadata, not message content. However, it could be used for reconnaissance or to track room changes after removal.

Deep Dive & Mechanics

The Sliding Sync feature in Synapse is designed to efficiently synchronize room state for clients. It uses a sliding window approach to send incremental state updates. The vulnerability arises from improper access control checks when processing state changes for rooms where the requesting user has been removed.

Root Cause: When a user is removed from a room (e.g., kicked, banned, or leaves), the Sliding Sync endpoint does not correctly filter out state events for that room. The server continues to include partial state changes (such as room name, topic, avatar, join rules) in the sync response for the removed user.

Affected Component: synapse/handlers/sliding_sync.py (or similar) – the logic that determines which rooms to include in the sync response for a given user.

Trigger: The vulnerability is triggered when a removed user makes a Sliding Sync request. The server incorrectly includes state events from rooms the user no longer belongs to.

Impact: An attacker can monitor changes to room metadata after being removed. This could reveal:

• Room name changes
• Topic updates
• Avatar changes
• Join rule modifications (e.g., from public to invite-only)

Non-state events (messages, reactions, etc.) are not leaked.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

# In sliding_sync handler
def get_sliding_sync_data(user_id, since_token):
    rooms = get_rooms_for_user(user_id)
    # BUG: Does not re-verify membership for rooms in the sync window
    for room in rooms:
        state_changes = get_state_changes_since(room, since_token)
        # state_changes includes events even if user was removed
        response.add_room_state(room, state_changes)

Patched Code (Conceptual):

# In sliding_sync handler
def get_sliding_sync_data(user_id, since_token):
    rooms = get_rooms_for_user(user_id)
    for room in rooms:
        # FIX: Verify current membership before including state
        if not is_user_in_room(user_id, room):
            continue
        state_changes = get_state_changes_since(room, since_token)
        response.add_room_state(room, state_changes)

The patch adds a membership check (is_user_in_room) before including state changes for any room. This ensures that only rooms the user currently belongs to are included in the sync response.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to a Synapse server running version 1.113.0rc1 to 1.120.0
• A valid user account that was previously a member of a target room
• Ability to make authenticated Sliding Sync requests

Exploitation Steps:

1. Identify Target Room: Join a room of interest on the vulnerable server.
2. Get Removed: Either leave the room, get kicked, or banned.
3. Monitor State Changes: After removal, continue making Sliding Sync requests. Observe that state changes (e.g., room name, topic) are still included in the response.

Example Request (using curl):

# Authenticate and get access token
ACCESS_TOKEN="your_token_here"

# Make a Sliding Sync request
curl -s -H "Authorization: Bearer $ACCESS_TOKEN" \
  "https://matrix.example.com/_matrix/client/v3/sync?since=s12345_6789" | \
  jq '.rooms.join'

Expected Result: The response will include state events from rooms the user no longer belongs to.

Blue Team

Detection:

• Monitor for Sliding Sync requests from users who have recently been removed from rooms.
• Look for anomalous sync patterns where a user receives state updates for rooms they should not have access to.

Hunting Query (Splunk):

index=matrix sourcetype=matrix_sync
| search "sliding_sync" AND "state"
| eval user_rooms=mvzip(user, room_id)
| where user NOT IN (SELECT user FROM room_membership WHERE membership='join')
| stats count by user, room_id

Lab Setup:

1. Deploy a vulnerable Synapse instance (e.g., version 1.115.0) using Docker.
2. Create two users: attacker and victim.
3. Have attacker join a room created by victim.
4. Remove attacker from the room (kick or ban).
5. Have victim change the room name.
6. Have attacker make a Sliding Sync request and observe the room name change.

Indicators of Compromise (IOCs)

• Network: Sliding Sync responses containing state events for rooms where the requesting user is not a member.
• Logs: Synapse logs showing sync requests for rooms with non-membership status.
• File: No specific file IOCs; the vulnerability is logic-based.

Example Log Entry (Suspicious):

2025-01-15 10:00:00,123 - synapse.handlers.sliding_sync - INFO - Returning state for room !abc:example.com to user @attacker:example.com (membership: leave)

Detection Engineering

YARA Rule

rule CVE_2024_53867_Synapse_SlidingSync_Leak {
    meta:
        description = "Detects Synapse Sliding Sync state leakage for removed users"
        author = "Valters IT"
        date = "2025-01-15"
        cve = "CVE-2024-53867"
    strings:
        $state_event = /"type":"m\.room\.(name|topic|avatar|join_rules)"/
        $sync_endpoint = "/_matrix/client/v3/sync"
        $user_id = /@[a-zA-Z0-9._%+-]+:[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/
    condition:
        $sync_endpoint and $state_event and #user_id > 0
}

Sigma Rule

title: CVE-2024-53867 Synapse Sliding Sync State Leak
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects potential exploitation of CVE-2024-53867 where a removed user receives room state changes via Sliding Sync.
author: Valters IT
date: 2025/01/15
logsource:
    category: application
    product: matrix
    service: synapse
detection:
    selection:
        event_type: "sliding_sync"
        membership: "leave"
        state_event: true
    condition: selection
falsepositives:
    - Legitimate sync requests for rooms the user just left (within a few seconds)
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-53867 Synapse Sliding Sync State Leak Attempt";
    flow:to_server,established;
    content:"/_matrix/client/v3/sync";
    http.uri;
    content:"since";
    http.client_body;
    pcre:"/\"type\":\"m\.room\.(name|topic|avatar|join_rules)\"/";
    classtype:attempted-recon;
    sid:10000001;
    rev:1;
)

Remediation & Mitigation

Immediate:

• Upgrade Synapse to version 1.120.1 or later.
• If immediate upgrade is not possible, restrict access to the Sliding Sync endpoint using a reverse proxy (e.g., Nginx) to only allow trusted clients.

Long-term:

• Implement regular security audits of access control logic.
• Add automated tests for membership verification in sync handlers.
• Monitor for similar vulnerabilities in other Matrix homeserver implementations.

Workaround:

• Disable the Sliding Sync feature entirely if not needed (configuration option experimental_features: sliding_sync: false).

Valters IT