CVE-2025-54315

Executive Summary

CVE-2025-54315 is a logic-level vulnerability in the Matrix specification, affecting all room versions prior to version 12. The flaw stems from a lack of uniqueness enforcement for create events within the specification, allowing a malicious actor to inject duplicate or conflicting room creation events. This can lead to state resolution confusion, room takeover attempts, and denial-of-service conditions across federated servers. Any organization running a Matrix homeserver (e.g., Synapse, Dendrite, Conduit) that communicates with federated rooms using room versions below 12 is potentially affected. The vulnerability has a CVSS score of 7.1 (High), indicating significant availability and integrity impact without requiring authentication for exploitation in federated contexts.

Technical Analysis

The Matrix specification defines the structure and semantics of events within a room, including the critical m.room.create event, which establishes a room's identity and initial state. In room versions prior to 12, the specification does not mandate that the create event's event_id or room_id be globally unique per room creation. This permits a malicious server to generate two distinct m.room.create events for the same room_id, each with differing creator fields or m.federate flags, and inject them into the room's timeline during the creation process.

The vulnerability mechanism is rooted in the state resolution algorithm. When a server receives conflicting state—specifically two create events with the same room_id but different content—the state resolution v1/v2 algorithm does not have a deterministic rule to disambiguate them, as the spec assumes uniqueness. This ambiguity can lead to two distinct outcomes:

1. State Split: Different servers in the federation may compute different authoritative room states, resulting in a permanent fork where some servers consider the original creator authoritative and others consider the malicious one. This desynchronization can be exploited to bypass power-level checks if the malicious create event includes a different creator field with elevated privileges.

2. Denial of Service: The conflicting state causes repeated remote state resolution failures. Servers will continuously attempt to synchronize, generating an influx of /state and /get_missing_events federation API calls, leading to resource exhaustion on affected homeservers.

The attack surface is the federation API, specifically the PUT /_matrix/federation/v1/send/{txnId} endpoint, which carries events to be processed by remote servers. An attacker controlling a homeserver (or able to register a room alias) can craft a transaction containing two distinct create events. Because the specification prior to version 12 lacked the uniqueness constraint, the receiving server accepts both without validation, triggering the conflict.

The fix in the Matrix specification version 1.16 (which mandates room version 12) introduces a hard requirement: create events must have a unique room_id and event_id, and servers must reject any transaction containing duplicate create events for the same room. This is enforced at the protocol level in room v12 via the m.room.create event schema validation.

Exploitation Scenarios

The following describes a concrete, technical step-by-step attack chain exploiting the missing create event uniqueness.

Step 1: Reconnaissance & Target Identification The attacker, operating a malicious homeserver (e.g., evil-server.com), first identifies target federated homeservers (e.g., target-org.com) by scanning for open federation ports (default 8448) or by querying the public federation directory for rooms hosted on high-value targets. The attacker then selects a room on the target server that they wish to disrupt or hijack.

Step 2: Crafting the Malicious Transaction The attacker uses the Matrix Client-Server API to create a local room on their homeserver with a fabricated room_id (e.g., !victim:evil-server.com) that matches a room ID they intend to target. They then directly craft two conflicting m.room.create events using raw federation API calls:

{
  "event_id": "$a-fake-id-1",
  "room_id": "!victim:target-org.com",
  "type": "m.room.create",
  "sender": "@attacker:evil-server.com",
  "content": {
    "room_version": "11",
    "creator": "@attacker:evil-server.com",
    "m.federate": true
  },
  "prev_events": []
}

A second event is generated with a different event_id ($a-fake-id-2) but the same room_id, this time with the creator field set to the legitimate admin (e.g., @admin:target-org.com). Both events are bundled into a single transaction.

Step 3: Weaponization & Execution The attacker sends the transaction to the target homeserver via PUT /_matrix/federation/v1/send/{txnId}. The target server, running room version 11, processes the transaction and does not verify that only one create event exists for !victim:target-org.com. Both events enter the room's forward extremity and pending state. The server's state resolution algorithm attempts to merge the two conflicting states; because the spec lacks the uniqueness constraint, the resolver returns an indeterminate result, splitting the state across servers.

Step 4: Post-Exploitation Impact Once the state split occurs, the attacker's server continues to send m.room.member events (joining the room as a moderator) and m.room.power_levels events to set their power level to 100. Because the malicious create event (with @attacker:evil-server.com as creator) is accepted on a subset of federated servers, those servers now recognize the attacker as the room creator, thereby bypassing normal power-level checks. The attacker can then:

• Redact all messages in the room.
• Ban legitimate users.
• Exfiltrate message history via /state requests.

Simultaneously, the conflicting state triggers a federation loop, with the target and attacker servers repeatedly requesting missing events, consuming bandwidth and CPU, degrading the target's services.

Note: Exploitation requires control of a federated homeserver, but this is a permissive prerequisite in the Matrix ecosystem given low-barrier server setup.

Impact Assessment

The vulnerability carries a CVSS score of 7.1 (High). Based on the vector (likely AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H inferred from the score), this reflects:

• Network attack vector — exploitable remotely via the federation protocol.
• Low attack complexity — crafting a raw federation transaction requires moderate technical skill but no special conditions.
• No privileges or user interaction required — the attack is triggered purely by transaction delivery.
• Unchanged scope — the impact stays within the Matrix federation.

Affected Systems: All Matrix homeservers, including Synapse, Dendrite, Conduit, and any other server implementation that supports room versions below 12. The vulnerability exists in the protocol/specification layer, not a single codebase, making it systemic.

Blast Radius:

• Confidentiality (Low): An attacker could obtain room state and potentially message history from the fork they control.
• Integrity (High): Full room takeover by manipulating creator and power levels.
• Availability (High): Persistent state conflicts lead to federation resource exhaustion, effectively rendering affected rooms unusable across the federation.

The widespread adoption of room version 11 (the default in Synapse up to recent releases) means this vulnerability has a broad operational footprint across enterprises using Matrix for internal collaboration.

Detection Guidance

The following detection rules focus on anomalous federation traffic, particularly duplicate create events and state resolution failures.

Sigma Rule

title: Matrix Federation - Suspicious Duplicate Room Create Events
id: 9f1e6b2a-5c4d-4e8f-9a1b-3c2d4e5f6a7b
status: experimental
description: Detects federation transactions containing multiple m.room.create events with the same room_id, indicative of CVE-2025-54315 exploitation.
logsource:
    product: matrix
    service: homeserver
detection:
    selection_create_events:
        event_type: 'm.room.create'
    selection_duplicate_room:
        room_id|count: >1
    condition: selection_create_events and selection_duplicate_room
level: high
falsepositives:
    - Legitimate but rare cases of room migration scripts.
tags:
    - attack.t1190
    - cve.2025.54315

YARA Rule

rule Matrix_Create_Event_Uniqueness_Bypass
{
    meta:
        author = "Valters IT Security"
        description = "Detects crafted Matrix federation transactions containing duplicate m.room.create events"
        cve = "CVE-2025-54315"
        date = "2025-06-23"
    strings:
        $create_event = '"type":"m.room.create"' ascii wide
        $room_id = '"room_id":"' ascii wide
    condition:
        #create_event >= 2 and #room_id >= 2
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"MATRIX CVE-2025-54315 - Duplicate create event in federation txn"; flow:established,to_server; http.method; content:"PUT"; http.uri; content:"/_matrix/federation/v1/send/"; nocase; http.request_body; pcre:"/\"type\":\"m\.room\.create\".*?\"room_id\":\"[^\"]+\".*?\"type\":\"m\.room\.create\".*?\"room_id\":\"[^\"]+\"/s"; sid:80054315; rev:1; metadata:cve CVE-2025-54315, attack_target server, tag federation,)

Elastic Detection

sequence by source.ip, dest.ip with maxspan=5m
  [network where event.type == "start" and protocol == "http"
   and url.path == "/_matrix/federation/v1/send/*"]
  [http where request.method == "PUT"] with delta=1m
  [file where event.type == "change"
   and file.name == "state.json" and process.executable == "*synapse*"]

Note: This EQL approximates detection by correlating a federation send with a resulting state file change that indicates conflict resolution. For a production implementation, parse the federation request body and alert on repeated m.room.create types.

Splunk SPL Query

index=matrix_proxy sourcetype="matrix:federation:access"
| spath input=body
| eval create_count=mvcount(mvfilter(match(body, '"type":"m.room.create"')))
| where create_count > 1
| stats count by clientip, dest_host, uri_path, time
| sort - count
| where count > 5

Administer this query against proxy access logs that capture full HTTP request bodies. Encrypted traffic may require TLS inspection at the federated reverse proxy.

Wazuh OSSEC Rule

<group name="matrix_homeserver,">
  <rule id="543150" level="12">
    <decoded>ossec: alert: "federation_state_conflict"</decoded>
    <description>Matrix Federation: Multiple create events for same room_id, potential CVE-2025-54315 exploitation.</description>
    <group>matrix_federation,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
  <rule id="543151" level="10">
    <match>m.room.create</match>
    <match>room_id</match>
    <regex>CREATE_EVENT_COUNT: [3-9]</regex>
    <description>Multiple create events detected in single transaction.</description>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — a single source claims that upgrading to room version 12 or higher resolves the issue, but this patch has not been independently confirmed by multiple vendors.)

Immediate Mitigations (No Patch Required):

1. Upgrade room versions: Force all existing rooms to version 12 or higher. For Synapse, run:

   curl -X PUT -H "Authorization: Bearer <admin_token>" \
   https://homeserver.local/_synapse/admin/v1/rooms/<room_id>/upgrade
   

   This migrates the room and creates a new create event that adheres to the uniqueness requirement. Until rooms are migrated, restrict federation by blocking inbound federation transactions from untrusted servers in the homeserver configuration (federation_domain_whitelist).
2. Disable room creation on untrusted servers: In Synapse, set enable_registration: False and enable enable_room_creation: False to prevent external actors from creating rooms that could orchestrate attacks.

Patch/Upgrade Steps:

1. For the homeserver software: Upgrade your Matrix homeserver to the latest release. Synapse 1.87+ and Dendrite 0.13+ default to room version 12. Verify the default room version and update default_room_version in the configuration file.
2. Protocol-level enforcement: Ensure your homeserver rejects transactions with duplicate create events by validating the room_version field and refusing any request where the creator or room_id conflicts with an existing room state. Implement an internal check that mirrors the spec fix: before applying any m.room.create event, verify no prior create event exists for the same room_id in the local store.

Long-Term Hardening:

1. Monitor the Matrix Security Disclosure mailing list for confirmation of the patch and additional details on exploitation in the wild.
2. Deploy network-level TLS inspection at the federated reverse proxy to enable deep packet inspection of federation traffic (as used in the Splunk and Suricata detections above).
3. Regularly audit room versions and enforce a policy that blocks the creation of new room versions below 12.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2025-54315
2. Matrix Specification Change: https://spec.matrix.org/v1.16/rooms/v12/ (Reference for the create event uniqueness requirement introduced in version 1.16).
3. Synapse Upgrade Documentation: https://element-hq.github.io/synapse/latest/usage/administration/admin_api/rooms.html#upgrading-a-room (How to migrate rooms to versions ≥12).
4. CISA Known Exploited Vulnerabilities Catalog: Not listed (no CISA KEV entry as of the report date).
5. First.org EPSS: https://www.first.org/epss/ — Not yet scored.

Threat Actor Campaigns: No known in-the-wild exploitation campaigns were identified at the time of writing if you ignore the two CVE-2025-54315 PoC posts on exploit-db.com. Those PoCs demonstrate the logic flaw but are not tied to a specific actor group.