Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
☕ Maven

GHSA-fpgf-pjjv-2qgm

HIGH

GHSA-fpgf-pjjv-2qgm is a high-severity (CVSS 8.6) Improper Authentication vulnerability in org.matrix.android:matrix-android-sdk2. O3 Security confirms whether GHSA-fpgf-pjjv-2qgm is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

matrix-android-sdk2 vulnerable to Olm/Megolm protocol confusion

Also known asCVE-2022-39248
Published
Sep 30, 2022
Updated
Nov 8, 2023
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Blast Radius

1 pkg affected
☕org.matrix.android:matrix-android-sdk2

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.

Description

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 [email protected].

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
☕Mavenorg.matrix.android:matrix-android-sdk2all versions1.5.1

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.matrix.android:matrix-android-sdk2. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update org.matrix.android:matrix-android-sdk2 to 1.5.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fpgf-pjjv-2qgm is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-fpgf-pjjv-2qgm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-fpgf-pjjv-2qgm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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-
O3 Security · Impact-Aware SCA

Is GHSA-fpgf-pjjv-2qgm in your dependencies?

O3 detects GHSA-fpgf-pjjv-2qgm across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works