CVE-2022-39248

highpriority · track · 30EPSS 0.010 · 63 %ileEUUS
grimoire priorityP2 · Scheduled
Exploitable?
—
no known exploitation
Likely / severe?
1.00% (63rd) EPSS
CVSS 7.5 · high
Is it mine?
3 products
Check your exposure
Who says so?
4 sources
cnnvd · enisa_euvd · nvd · osv

EPSS · scored 2026-10-27

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.

01

cvss

Technical severity, 0–10. One row per scoring source.

8.6
010

base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · medium–high · 6.9–8.6

v3.17.5highCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:Nprimary · NVD / NIST USexploitability 3.9 · impact 3.6
v3.18.6highCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:Nsecondary · ENISA EU
v3.18.6highCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:Nsecondary · security-advisories@github.comexploitability 3.9 · impact 4
v3.18.6highCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:Nsecondary · OSV
v3.16.9mediumCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N/E:Usecondary · CVSS-BT (t0sche)
02

ssvc

A stakeholder decision — act, attend, or track — from exploitation and impact.

Exploitation: none · Automatable: yes · Technical Impact: partialcoordinatorcisa_ssvcUS
03

weaknesses

The CWE weakness classes this flaw belongs to.

04

affected products (3)

Products and version ranges known to be affected.

05

advisories (1)

Vendor and ecosystem advisories describing this.

  • GHSA-fpgf-pjjv-2qgmmatrix-android-sdk2 vulnerable to Olm/Megolm protocol confusion2022-09-30ghsa · osvUS

    ### 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. 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. ### Patches matrix-android-sdk2 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: - 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 which managed to decrypt the message, and not by using claimed sender_key, user_id, or any other fields controllable by the homeserver. ### Workarounds As this attack requires coordination between a malicious home server and an attacker, if you trust your home server no particular workaround is needed. Notice that the backup spoofing attack is a particularly sophisticated targeted attack. We are not aware of this attack being used in the wild, though specifying a false positive-free way of noticing malicious key backups key is challenging. As an abundance of caution, to avoid malicious backup attacks, you should not verify your new logins using emoji/QR verifications methods until patched. Prefer using verify with passphrase. ### References Blog post: https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients ### For more information If you have any questions or comments about this advisory, e-mail us at [security@matrix.org](mailto:security@matrix.org).

06

also known as (3)

Other names and identifiers for this entity.

07

sources

Which sources assert this record, and when.

published 2022-09-28modified 2026-06-17
08

references (13)

External citations — patches, advisories, analysis.

scry

Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.

Free scan