{"id":"CVE-2026-45056","aliases":["EUVD-2026-76763","GHSA-wfq4-36m3-9g42","RUSTSEC-2026-0159"],"status":"published","title":"Matrix Rust SDK: Sender-binding gaps in to-device and room-key attribution","description":"matrix-sdk-crypto is a no-network-IO implementation of a state machine that handles end-to-end encryption for Matrix clients. Starting in version 0.12.0 and prior to version 0.17.0, the matrix-sdk-crypto crate was missing a check for the user ID when decrypting an Olm-encrypted event containing the `sender_device_keys` property. This could be exploited to forge an encrypted to-device event, but only if the attacker colludes with the homeserver operator. This issue is fixed in matrix-sdk-crypto 0.17.0. There are no known workarounds for the issue.","severity":{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00308,"percentile":0.23866,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-290"],"published":"2026-06-03T12:00:00Z","modified":"2026-11-04T02:47:35Z","fixes":[{"ecosystem":"crates.io","package":"matrix-sdk-crypto","fixed_in":["0.16.1"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"crates.io","package":"matrix-sdk-crypto","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.12.0"},{"fixed":"0.16.1"}]}]},{"source":"osv","ecosystem":"crates.io","package":"matrix-sdk-crypto","ranges":[{"type":"SEMVER","events":[{"introduced":"0.12.0"},{"fixed":"0.16.1"}]}]},{"source":"osv","ecosystem":"crates.io","package":"matrix-sdk-crypto","ranges":[{"type":"SEMVER","events":[{"introduced":"0.12.0"},{"fixed":"0.16.1"}]}]}],"products":[{"vendor":"matrix-org","product":"matrix-rust-sdk"}],"references":[{"url":"https://github.com/matrix-org/matrix-rust-sdk/security/advisories/GHSA-wfq4-36m3-9g42","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/matrix-org/matrix-rust-sdk/pull/6553","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/matrix-org/matrix-rust-sdk/releases/tag/matrix-sdk-0.16.1","tags":["x_refsource_MISC","web"]},{"url":"https://rustsec.org/advisories/RUSTSEC-2026-0159.html","tags":["x_refsource_MISC","advisory","web"]},{"url":"https://github.com/advisories/GHSA-wfq4-36m3-9g42"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/45xxx/CVE-2026-45056.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45056","tags":["advisory"]},{"url":"https://github.com/matrix-org/matrix-rust-sdk","tags":["package"]},{"url":"https://crates.io/crates/matrix-sdk-crypto","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-45056","title":"Matrix Rust SDK: Sender-binding gaps in to-device and room-key attribution","description":"matrix-sdk-crypto is a no-network-IO implementation of a state machine that handles end-to-end encryption for Matrix clients. Starting in version 0.12.0 and prior to version 0.17.0, the matrix-sdk-crypto crate was missing a check for the user ID when decrypting an Olm-encrypted event containing the `sender_device_keys` property. This could be exploited to forge an encrypted to-device event, but only if the attacker colludes with the homeserver operator. This issue is fixed in matrix-sdk-crypto 0.17.0. There are no known workarounds for the issue.","status":"published","published":"2026-09-11T21:13:56.332Z","modified":"2026-09-14T18:17:31.91Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"medium","assessor":"cna"}],"cwes":["CWE-290"],"updated_at":"2026-11-02T13:46:32.755125Z"}],"euvd":[{"id":"EUVD-2026-76763","description":"matrix-sdk-crypto is a no-network-IO implementation of a state machine that handles end-to-end encryption for Matrix clients. Starting in version 0.12.0 and prior to version 0.17.0, the matrix-sdk-crypto crate was missing a check for the user ID when decrypting an Olm-encrypted event containing the `sender_device_keys` property. This could be exploited to forge an encrypted to-device event, but only if the attacker colludes with the homeserver operator. This issue is fixed in matrix-sdk-crypto 0.17.0. There are no known workarounds for the issue.","status":"published","published":"2026-09-11T21:13:56Z","modified":"2026-09-14T18:17:31Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T17:28:19.730872Z"}],"ghsa":[{"id":"GHSA-wfq4-36m3-9g42","title":"Matrix Rust SDK: Sender-binding gaps in to-device and room-key attribution","description":"### Impact\n\nThe `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.\n\nThis 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.\n\n### Patches\n\nThis issue is fixed in `matrix-sdk-crypto` 0.16.1.\n\n### Workarounds\n\nThere are no known workarounds for the issue.\n\n### References\n\nThis issue was fixed in https://github.com/matrix-org/matrix-rust-sdk/pull/6553.\n\n### For more information\n\nIf you have any questions or comments about this advisory, please email us at [security at matrix.org](mailto:security@matrix.org).","status":"published","published":"2026-06-04T14:47:05Z","modified":"2026-06-04T14:47:05Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-290"],"updated_at":"2026-11-02T14:40:16.698699Z"}],"nvd":[{"id":"CVE-2026-45056","description":"matrix-sdk-crypto is a no-network-IO implementation of a state machine that handles end-to-end encryption for Matrix clients. Starting in version 0.12.0 and prior to version 0.17.0, the matrix-sdk-crypto crate was missing a check for the user ID when decrypting an Olm-encrypted event containing the `sender_device_keys` property. This could be exploited to forge an encrypted to-device event, but only if the attacker colludes with the homeserver operator. This issue is fixed in matrix-sdk-crypto 0.17.0. There are no known workarounds for the issue.","status":"published","published":"2026-09-11T22:16:37.263Z","modified":"2026-09-30T19:57:08.043Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium","assessor":"secondary"}],"cwes":["CWE-290"],"updated_at":"2026-11-02T14:12:46.62721Z"}],"osv":[{"id":"CVE-2026-45056","title":"Matrix Rust SDK: Sender-binding gaps in to-device and room-key attribution","description":"matrix-sdk-crypto is a no-network-IO implementation of a state machine that handles end-to-end encryption for Matrix clients. Starting in version 0.12.0 and prior to version 0.17.0, the matrix-sdk-crypto crate was missing a check for the user ID when decrypting an Olm-encrypted event containing the `sender_device_keys` property. This could be exploited to forge an encrypted to-device event, but only if the attacker colludes with the homeserver operator. This issue is fixed in matrix-sdk-crypto 0.17.0. There are no known workarounds for the issue.","status":"published","published":"2026-09-11T21:13:56.332Z","modified":"2026-11-04T02:47:35.005231977Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-290"],"updated_at":"2026-11-04T02:53:45.692342Z"},{"id":"GHSA-wfq4-36m3-9g42","title":"Matrix Rust SDK: Sender-binding gaps in to-device and room-key attribution","description":"### Impact\n\nThe `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.\n\nThis 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.\n\n### Patches\n\nThis issue is fixed in `matrix-sdk-crypto` 0.16.1.\n\n### Workarounds\n\nThere are no known workarounds for the issue.\n\n### References\n\nThis issue was fixed in https://github.com/matrix-org/matrix-rust-sdk/pull/6553.\n\n### For more information\n\nIf you have any questions or comments about this advisory, please email us at [security at matrix.org](mailto:security@matrix.org).","status":"published","published":"2026-06-04T14:47:05Z","modified":"2026-06-04T15:00:08.09217251Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-290"],"updated_at":"2026-11-02T15:46:58.401149Z"},{"id":"RUSTSEC-2026-0159","title":"Sender-binding gaps in to-device messages","description":"The matrix-sdk-crypto crate before 0.16.1 is missing a check for the sender's\nuser ID when decrypting an Olm-encrypted to-device message containing the\nsender_device_keys property.\n\nThis could be exploited to spoof the sender of an encrypted to-device message,\nbut only if the attacker colludes with (or is) the homeserver operator.","status":"published","published":"2026-06-03T12:00:00Z","modified":"2026-10-12T18:00:09.240103517Z","updated_at":"2026-11-02T15:53:40.430679Z"}]}}