https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 22:55:03 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-233560 EUVD-2026-233560 https://cve.radiocsirt.org/vuln/euvd-2026-233560 https://cve.radiocsirt.org/vuln/fkie_cve-2022-39248 <p>matrix-android-sdk2 is the Matrix SDK for Android. Prior to version 1.5.1, an attacker cooperating with a malicious homeserver can construct messages that legitimately appear to have come from another person, without any indication such as a grey shield. Additionally, a sophisticated attacker cooperating with a malicious homeserver could employ this vulnerability to perform a targeted attack in order to send fake to-device messages appearing to originate from another user. This can allow, for example, to inject the key backup secret during a self-verification, to make a targeted device start using a malicious key backup spoofed by the homeserver. matrix-android-sdk2 would then additionally sign such a key backup with its device key, spilling trust over to other devices trusting the matrix-android-sdk2 device. These attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm. matrix-android-sdk2 version 1.5.1 has been modified to only accept Olm-encrypted to-device messages and to stop signing backups on a successful decryption. Out of caution, several other checks have been audited or added. This attack requires coordination between a malicious home server and an attacker, so those who trust their home servers do not need a workaround.</p> <p>matrix-android-sdk2 is the Matrix SDK for Android. Prior to version 1.5.1, an attacker cooperating with a malicious homeserver can construct messages that legitimately appear to have come from another person, without any indication such as a grey shield. Additionally, a sophisticated attacker cooperating with a malicious homeserver could employ this vulnerability to perform a targeted attack in order to send fake to-device messages appearing to originate from another user. This can allow, for example, to inject the key backup secret during a self-verification, to make a targeted device start using a malicious key backup spoofed by the homeserver. matrix-android-sdk2 would then additionally sign such a key backup with its device key, spilling trust over to other devices trusting the matrix-android-sdk2 device. These attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm. matrix-android-sdk2 version 1.5.1 has been modified to only accept Olm-encrypted to-device messages and to stop signing backups on a successful decryption. Out of caution, several other checks have been audited or added. This attack requires coordination between a malicious home server and an attacker, so those who trust their home servers do not need a workaround.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2022-39248 https://cve.radiocsirt.org/vuln/ghsa-fpgf-pjjv-2qgm <p><strong>Affected:</strong> Maven: org.matrix.android:matrix-android-sdk2</p> <p>### Impact An attacker cooperating with a malicious homeserver can construct messages that legitimately appear to have come from another person, without any indication such as a grey shield.</p> <p>Additionally, a sophisticated attacker cooperating with a malicious homeserver could employ this vulnerability to perform a targeted attack in order to send fake to-device messages appearing to originate from another user. This can allow, for example, to inject the key backup secret during a self-verification, to make a targeted device start using a malicious key backup spoofed by the homeserver. matrix-android-sdk2 would then additionally sign such a key backup with its device key, spilling trust over to other devices trusting the matrix-android-sdk2 device.</p> <p>These attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm.</p> <p>### Patches</p> <p>matrix-android-sdk2 has been modified to only accept Olm-encrypted to-device messages and to stop signing backups on a successful decryption.</p> <p>Out of caution, several other checks have been audited or added: - Cleartext `m.room_key`, `m.forwarded_room_key` and `m.secret.send` to_device messages are discarded. - Secrets received from untrusted devices are discarded. - Key backups are only usable if they have a valid signature from a trusted device (no more local trust, or trust-on-decrypt). - The origin of a to-device message should only be determined by observing the Olm session…</p> <p><strong>Affected:</strong> Maven: org.matrix.android:matrix-android-sdk2</p> <p>### Impact An attacker cooperating with a malicious homeserver can construct messages that legitimately appear to have come from another person, without any indication such as a grey shield.</p> <p>Additionally, a sophisticated attacker cooperating with a malicious homeserver could employ this vulnerability to perform a targeted attack in order to send fake to-device messages appearing to originate from another user. This can allow, for example, to inject the key backup secret during a self-verification, to make a targeted device start using a malicious key backup spoofed by the homeserver. matrix-android-sdk2 would then additionally sign such a key backup with its device key, spilling trust over to other devices trusting the matrix-android-sdk2 device.</p> <p>These attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm.</p> <p>### Patches</p> <p>matrix-android-sdk2 has been modified to only accept Olm-encrypted to-device messages and to stop signing backups on a successful decryption.</p> <p>Out of caution, several other checks have been audited or added: - Cleartext `m.room_key`, `m.forwarded_room_key` and `m.secret.send` to_device messages are discarded. - Secrets received from untrusted devices are discarded. - Key backups are only usable if they have a valid signature from a trusted device (no more local trust, or trust-on-decrypt). - The origin of a to-device message should only be determined by observing the Olm session…</p> https://cve.radiocsirt.org/vuln/ghsa-fpgf-pjjv-2qgm https://cve.radiocsirt.org/vuln/gsd-2022-39248 gsd-2022-39248 https://cve.radiocsirt.org/vuln/gsd-2022-39248