matrix-sdk-crypto CVE-2026-45056
MEDIUMLifecycle Timeline
2DescriptionCVE.org
Impact
The matrix-sdk-crypto crate before 0.16.1 is missing a check for the sender's user ID when decrypting an Olm-encrypted to-device message containing the sender_device_keys property.
This could be exploited to spoof the sender of an encrypted to-device message, but only if the attacker colludes with (or is) the homeserver operator.
Patches
This issue is fixed in matrix-sdk-crypto 0.16.1.
Workarounds
There are no known workarounds for the issue.
References
This issue was fixed in https://github.com/matrix-org/matrix-rust-sdk/pull/6553.
For more information
If you have any questions or comments about this advisory, please email us at [security at matrix.org](mailto:security@matrix.org).
AnalysisAI
Sender identity spoofing in matrix-sdk-crypto (Rust crate) versions 0.12.0 through 0.16.0 allows a malicious or colluding homeserver operator to forge the apparent sender of Olm-encrypted to-device messages by supplying manipulated sender_device_keys without a corresponding user ID validation check. The vulnerability is classified as CWE-290 (Authentication Bypass by Spoofing) and is patched in version 0.16.1. No public exploit code exists and this CVE is not listed in CISA KEV, but the attack's reliance on homeserver-level access defines a concrete and realistic threat model for federated Matrix deployments where server trust is not absolute.
Technical ContextAI
The Matrix protocol uses the Olm cryptographic ratchet for encrypted to-device messages, which are direct device-to-device communications outside of room context. The matrix-sdk-crypto crate (pkg:rust/matrix-sdk-crypto) implements this layer in the Matrix Rust SDK. When decrypting an incoming Olm to-device message, the crate processes an optional sender_device_keys property embedded in the plaintext payload. Prior to 0.16.1, the code failed to verify that the user_id field within sender_device_keys matched the authenticated sender identity established by the Olm session itself. CWE-290 (Authentication Bypass by Spoofing) precisely describes this root cause: a trusted identity claim is accepted without binding it to the channel-verified identity. The PR diff confirms the fix adds explicit validation rejecting messages where the embedded sender_device_keys.user_id does not match the Olm session's sender, and also tightens checks for unsigned device keys and mismatched Ed25519 keys.
RemediationAI
Upgrade matrix-sdk-crypto to version 0.16.1 or later. The fix is available via the matrix-sdk-0.16.1 release tag at https://github.com/matrix-org/matrix-rust-sdk/releases/tag/matrix-sdk-0.16.1 and the upstream patch is in PR #6553 (https://github.com/matrix-org/matrix-rust-sdk/pull/6553). Downstream applications consuming this crate should update their Cargo.toml dependency and rebuild. The vendor confirms no known workarounds exist for this issue, meaning disabling specific features or configuration changes cannot mitigate the missing validation. For deployments where upgrading immediately is not feasible, restricting federation to known-trusted homeservers reduces exposure since exploitation requires homeserver-level access, though this is an operational control, not a code-level fix. Contact security@matrix.org for additional guidance.
Same weakness CWE-290 – Authentication Bypass by Spoofing
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-wfq4-36m3-9g42