CVE-2025-48937: matrix-rust-sdk Auth Bypass Vulnerability

CVE-2025-48937 Overview

CVE-2025-48937 affects matrix-sdk-crypto, the cryptographic component of the matrix-rust-sdk client library. The library fails to validate that the sender of an encrypted event matches the owner of the Megolm session used to encrypt it. A malicious homeserver operator can exploit this authentication weakness [CWE-290] to modify events served to clients, making messages appear as if they were sent by a different user. The flaw impacts matrix-sdk-crypto from version 0.8.0 through 0.11.0 and is fixed in 0.11.1 and 0.12.0.

Critical Impact
A malicious homeserver operator can impersonate arbitrary users in end-to-end encrypted Matrix rooms, undermining the integrity guarantees of the Megolm protocol.

Affected Products

matrix-rust-sdk matrix-sdk-crypto 0.8.0 through 0.11.0
Matrix clients built on the affected matrix-sdk-crypto versions
Downstream applications using the Rust implementation of the Matrix client-server library

Discovery Timeline

2025-06-10 - CVE-2025-48937 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-48937

Vulnerability Analysis

The vulnerability originates in the Megolm session handling logic of matrix-sdk-crypto. When decrypting an encrypted event, the client resolves sender information from the Megolm session's SenderData but does not compare the resolved user ID against the sender identifier in the event envelope. This omission allows a homeserver to deliver an event authored by user A while attributing it to user B in the envelope, and the recipient client accepts the mismatch without warning.

The Matrix end-to-end encryption model relies on Megolm session ownership binding an encryption key to a specific user and device. When the SDK skips the sender-to-session ownership check, the cryptographic authenticity guarantee of the m.megolm.v1.aes-sha2 algorithm collapses at the client layer.

Root Cause

The decryption pipeline called sender_data_to_verification_state without first comparing sender_data.user_id() to the event sender. The SenderData enum stores the true owner of a Megolm session, but no code path enforced equality between that owner and the sender field placed in the event by the homeserver. A homeserver operator with control over event routing could therefore substitute the sender field freely.

Attack Vector

Exploitation requires operator-level control of a Matrix homeserver serving the victim. The attacker crafts or reroutes an encrypted event so the envelope sender differs from the true session owner. The victim's client decrypts the payload using the legitimate session key and displays the message as originating from the substituted user. No user interaction is required, and no cryptographic key material is compromised.

rust

) -> MegolmResult<(VerificationState, Option<OwnedDeviceId>)> {
    let sender_data = self.get_or_update_sender_data(session, sender).await?;

    // If the user ID in the sender data doesn't match that in the event envelope,
    // this event is not from who it appears to be from.
    //
    // If `sender_data.user_id()` returns `None`, that means we don't have any
    // information about the owner of the session (i.e. we have
    // `SenderData::UnknownDevice`); in that case we fall through to the
    // logic in `sender_data_to_verification_state` which will pick an appropriate
    // `DeviceLinkProblem` for `VerificationLevel::None`.
    let (verification_state, device_id) = match sender_data.user_id() {
        Some(i) if i != sender => {
            // For backwards compatibility, we treat this the same as "Unknown device".
            // TODO: use a dedicated VerificationLevel here.
            (
                VerificationState::Unverified(VerificationLevel::None(
                    DeviceLinkProblem::MissingDevice,
                )),
                None,
            )
        }

        Some(_) | None => {
            sender_data_to_verification_state(sender_data, session.has_been_imported())
        }
    };

Source: GitHub Commit 13c1d20. The patch introduces the explicit mismatch check that was previously absent.

Detection Methods for CVE-2025-48937

Indicators of Compromise

Encrypted Matrix events in which the envelope sender does not correspond to the owner of the Megolm session key used for decryption.
Client logs showing sudden appearance of VerificationLevel::None or DeviceLinkProblem::MissingDevice after upgrading to 0.11.1 or 0.12.0, indicating historically forged events.
Client applications running matrix-sdk-crypto versions between 0.8.0 and 0.11.0 as reported by dependency inventories or SBOM tooling.

Detection Strategies

Inventory all applications and packages depending on matrix-sdk-crypto using cargo tree or SBOM analysis and flag any version in the vulnerable range.
Correlate homeserver access logs with unexpected federation traffic or administrative access that could indicate operator-level tampering.
Review room event history in high-value channels for messages that clients now flag as unverified following an SDK upgrade.

Monitoring Recommendations

Track new releases and advisories from the matrix-org GitHub organization, including GHSA-x958-rvg6-956w.
Monitor client-side telemetry for verification-state downgrades on previously trusted senders.
Alert on the presence of vulnerable matrix-sdk-crypto versions in continuous integration and production builds.

How to Mitigate CVE-2025-48937

Immediate Actions Required

Upgrade matrix-sdk-crypto to 0.11.1 or 0.12.0 in all client applications and rebuild dependent binaries.
Audit downstream Matrix clients and forks to confirm they consume the patched release rather than a pinned vulnerable version.
For federated deployments, review the trust posture of homeservers users connect to and restrict clients to trusted operators where feasible.

Patch Information

The fix is delivered in matrix-sdk-crypto versions 0.11.1 and 0.12.0. The two upstream commits, 13c1d20 and 5698074, introduce a user_id() accessor on SenderData and compare it against the event envelope sender before assigning a VerificationState. See the GitHub Security Advisory GHSA-x958-rvg6-956w and the Matrix Spec Client-Server API for protocol context.

Workarounds

No supported workaround exists; users must upgrade to a patched matrix-sdk-crypto version.
Where upgrade is delayed, restrict client use to homeservers operated by trusted parties to reduce the risk of operator-level event tampering.
Treat any sender attribution in high-trust rooms with additional out-of-band verification until clients are patched.

bash

# Update the dependency in Cargo.toml and refresh the lockfile
cargo update -p matrix-sdk-crypto --precise 0.12.0
cargo build --release