GHSA-5w8r-8pgj-5jmf
HIGHmatrix-js-sdk subject to user impersonation due to key/device identifier confusion in SAS verification
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
matrix-js-sdknpmDescription
Impact
An attacker cooperating with a malicious homeserver could interfere with the verification flow between two users, injecting its own cross-signing user identity in place of one of the users’ identities, leading to the other device trusting/verifying the user identity under the control of the homeserver instead of the intended one.
The vulnerability is a bug in the matrix-js-sdk, caused by checking and signing user identities and devices in two separate steps, and inadequately fixing the keys to be signed between those steps.
Even though the attack is partly made possible due to the design decision of treating cross-signing user identities as Matrix devices on the server side (with their device ID set to the public part of the user identity key), no other examined implementations were vulnerable.
Patches
The matrix-js-sdk has been modified to double check that the key signed is the one that was verified instead of just referencing the key by ID. An additional check has been made to report an error when one of the device ID matches a cross-signing key.
Workarounds
As this attack requires coordination between a malicious homeserver and an attacker -- if you trust your homeserver no particular workaround is needed.
As a potential way of detecting compromise, it’s possible to review your device list or the device list of other users for devices with IDs in the form of a base64 cross-signing key (5XaczGNlfz0bl8R1IX5qn+tBoue2tWJqLMh+SDUuvCk) instead of classical device ID (SEHACYDHMG).
References
For more information
If you have any questions or comments about this advisory, e-mail us at [email protected]
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | matrix-js-sdk | all versions | 19.7.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for matrix-js-sdk. 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.
Fix
Update matrix-js-sdk to 19.7.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5w8r-8pgj-5jmf is resolved across your whole dependency graph.
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.
How O3 protects you
O3 pinpoints whether GHSA-5w8r-8pgj-5jmf 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-5w8r-8pgj-5jmf. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-5w8r-8pgj-5jmf in your dependencies?
O3 detects GHSA-5w8r-8pgj-5jmf across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.