CVE-2026-45056: 
Rust vulnerability analysis and mitigation

CVE-2026-45056 is a sender spoofing vulnerability in the matrix-sdk-crypto Rust crate, titled "Sender-binding gaps in to-device messages allow for sender spoofing." The flaw affects versions >= 0.12.0 and < 0.16.1 of matrix-sdk-crypto (part of the matrix-rust-sdk project) and was published on June 3–4, 2026. It carries a CVSS v4.0 base score of 6.9 (Medium/Moderate) (Github Advisory). The vulnerability was fixed in matrix-sdk-crypto 0.16.1, released May 8, 2026 (matrix-sdk-0.16.1 Release).

The root cause is a missing validation check (CWE-290: Authentication Bypass by Spoofing; CWE-347: Improper Verification of Cryptographic Signature) in the Olm message decryption logic within crates/matrix-sdk-crypto/src/olm/account.rs. When decrypting an Olm-encrypted to-device message that contains the sender_device_keys property, the library failed to verify that the user ID embedded in those device keys matched the actual sender of the message. An attacker who controls or colludes with a homeserver operator can craft a malicious Olm-encrypted to-device message with a forged sender_device_keys property, causing the recipient client to attribute the message to an arbitrary user identity. The fix, introduced in PR #6553, adds the missing user ID check against the embedded device keys (Github Advisory, PR #6553).

Successful exploitation allows an attacker (acting as or colluding with a homeserver operator) to forge the sender identity of encrypted to-device messages, causing recipients to believe a message originated from a different Matrix user than the actual sender. This is a pure integrity impact — there is no confidentiality or availability impact — but it undermines the trust model of Matrix's end-to-end encryption for to-device messaging, potentially enabling impersonation attacks, social engineering, or manipulation of cryptographic key exchange flows that rely on authenticated sender identity (Github Advisory, Red Hat Bugzilla).

Exploitation requires the attacker to control or collude with a Matrix homeserver operator, making this a high-privilege, non-trivial attack scenario. There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Github Advisory). The EPSS score is approximately 0.05% (0.000500), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no threat actor attribution has been reported.

1. Prerequisite — Homeserver Control: The attacker must operate or have administrative access to a Matrix homeserver that is federated with the target user's homeserver, or must collude with the target's homeserver operator.
2. Identify Target: Determine the Matrix user ID of the intended victim and the device to which the forged to-device message will be sent.
3. Craft Malicious Olm Message: Construct an Olm-encrypted to-device message that includes a sender_device_keys property containing device key material belonging to a different (spoofed) Matrix user ID — not the actual sender.
4. Deliver via Homeserver: Use homeserver-level access to inject or relay this crafted message to the target client, bypassing normal federation checks.
5. Exploit Missing Validation: The vulnerable matrix-sdk-crypto client decrypts the Olm message without verifying that the user ID in sender_device_keys matches the actual message sender, causing it to attribute the message to the spoofed user.
6. Achieve Impersonation: The recipient client now believes the to-device message (e.g., a key share request or verification message) originated from the spoofed user, potentially enabling further social engineering or cryptographic key manipulation (Github Advisory, PR #6553).

No specific IOCs have been publicly documented for this vulnerability, as exploitation requires homeserver-level access and leaves no distinctive client-side artifacts. Defenders operating Matrix homeservers should monitor for anomalous to-device message traffic patterns.

The fix is available in matrix-sdk-crypto version 0.16.1 (released May 8, 2026) as part of the matrix-rust-sdk 0.16.1 release. Developers and downstream consumers of the matrix-sdk-crypto crate should upgrade to version 0.16.1 or later immediately. There are no known workarounds for this vulnerability — upgrading is the only remediation (Github Advisory, matrix-sdk-0.16.1 Release).