Listen to this Post
The vulnerability stems from the matrix-sdk-crypto crate’s failure to validate the sender’s user ID when processing an Olm-encrypted to-device message that includes a sender_device_keys property. In the Matrix protocol, to-device messages are used for direct, encrypted communication between devices without involving room events. The affected versions incorrectly assume that the authenticated Olm session (identified by a session ID) is sufficient to guarantee the identity of the message sender. The session is indeed established using one-time keys and a shared secret, but the library’s state machine (OlmMachine) does not cross-check the user ID attached to the decrypted message against the user ID that owns the Olm session. The impact of this oversight is severe: a malicious homeserver operator—or an attacker colluding with one—can spoof the origin of a to-device message. By modifying the sender_device_keys field, the attacker can make it appear that a message came from a different, trusted user. This breaks the core authenticity guarantee of end-to-end encryption, potentially leading to cross-device impersonation, trust chain violations, or social engineering. The vulnerability affects all versions before 0.16.1, but only scenarios where the attacker has control over the homeserver (a plausible threat model when using untrusted or federated servers). The root cause lies in the decryption path: after successfully decrypting a message, the code extracts the sender’s device keys but never compares the claimed sender (from the event envelope) with the owner of the cryptographic session that actually delivered the message. The issue was fixed in matrix-sdk-crypto 0.16.1 by adding a direct check: upon decrypting a to-device message, the library now retrieves the user ID associated with the session (sender_data.user_id()) and compares it with the user ID present in the event’s sender field. If they mismatch, the decryption fails and the message is discarded.
DailyCVE Form:
Platform: matrix-sdk-crypto
Version: 0.16.1
Vulnerability: Missing sender check
Severity: Medium
date: 2026-06-03
Prediction: Already patched 0.16.1
What Undercode Say:
Check installed version of matrix-sdk-crypto
cargo tree | grep matrix-sdk-crypto
Simulate a failed decryption due to missing sender check (conceptual)
This would return an OK status but the message would be spoofed in vulnerable versions
Example: attempting to decrypt a maliciously crafted Olm message
cargo run --example decrypt_malicious -- --input spoofed_message.msg
The vulnerable code path (pseudocode)
if session.user_id() != event.sender { panic!("sender mismatch"); } // missing in <0.16.1
Exploit:
An attacker with homeserver access modifies the sender_device_keys field of an Olm-encrypted to-device message before forwarding it to the target. The vulnerable client decrypts the message and accepts the spoofed sender identity because no user ID check occurs. This can be used to forge key verification requests or other sensitive to-device events.
Protection:
Upgrade to matrix-sdk-crypto 0.16.1 or later. If immediate upgrade is impossible, implement an application‑layer validation that compares the event’s sender field against the user ID derived from the Olm session. Also restrict trust to homeservers you control.
Impact:
An attacker can spoof the sender of encrypted to‑device messages, undermining end‑to‑end authenticity. This could lead to successful impersonation of trusted users, acceptance of malicious device keys, and bypass of cross‑signing verification, all within the encrypted channel.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
