Package Instance

matrix-js-sdk has insufficient MXC URI validation which allows client-side path traversal
### Summary

matrix-js-sdk before 34.11.0 is vulnerable to client-side path traversal via crafted MXC URIs. A malicious room member can trigger clients based on the matrix-js-sdk to issue arbitrary authenticated GET requests to the client's homeserver.

### Details

The Matrix specification demands homeservers to [perform validation](https://spec.matrix.org/v1.12/client-server-api/#security-considerations-5) of the `server-name` and `media-id` components of MXC URIs with the intent to prevent path traversal. However, it is not mentioned that a similar check must also be performed on the client to prevent *client-side* path traversal. matrix-js-sdk fails to perform this validation.

### Patches

Fixed in matrix-js-sdk 34.11.1.

### Workarounds

None.

### References

- https://spec.matrix.org/v1.12/client-server-api/#security-considerations-5
- https://blog.doyensec.com/2024/07/02/cspt2csrf.html

matrix-js-sdk will freeze when a user sets a room with itself as a its predecessor
### Impact
A malicious homeserver can craft a room or room structure such that the predecessors form a cycle. The matrix-js-sdk's `getRoomUpgradeHistory` function will infinitely recurse in this case, causing the code to hang. This method is public but also called by the 'leaveRoomChain()' method, so leaving a room will also trigger the bug.

Even if the CVSS score would be 4.1 ([AV:N/AC:L/PR:L/UI:R/S:C/C:N/I:N/A:L](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:L/UI:R/S:C/C:N/I:N/A:L&version=3.1)) we classify this as High severity issue.

### Patches
This was patched in matrix-js-sdk 34.3.1.

### Workarounds
Sanity check rooms before passing them to the matrix-js-sdk or avoid calling either `getRoomUpgradeHistory` or `leaveRoomChain`.

### References
N/A.

Matrix JavaScript SDK's key history sharing could share keys to malicious devices
### Impact
In matrix-js-sdk versions 9.11.0 through 34.7.0, the method `MatrixClient.sendSharedHistoryKeys` is vulnerable to interception by malicious homeservers.  The method implements functionality proposed in [MSC3061](https://github.com/matrix-org/matrix-spec-proposals/pull/3061) and can be used by clients to share historical message keys with newly invited users, granting them access to past messages in the room.

However, it unconditionally sends these "shared" keys to all of the invited user's devices, regardless of whether the user's cryptographic identity is verified or whether the user's devices are signed by that identity. This allows the attacker to potentially inject its own devices to receive sensitive historical keys without proper security checks.

Note that this only affects clients running the SDK with the legacy crypto stack. Clients using the new Rust cryptography stack (i.e. those that call `MatrixClient.initRustCrypto()` instead of `MatrixClient.initCrypto()`) are unaffected by this vulnerability, because `MatrixClient.sendSharedHistoryKeys()` raises an exception in such environments.

### Patches
Fixed in matrix-js-sdk 34.8.0 by removing the vulnerable functionality.

### Workarounds
Remove use of affected functionality from clients.

### References
- [MSC3061](https://github.com/matrix-org/matrix-spec-proposals/pull/3061)

### For more information
If you have any questions or comments about this advisory, please email us at [security at matrix.org](mailto:security@matrix.org).

matrix-js-sdk has insufficient validation when considering a room to be upgraded by another
matrix-js-sdk before 38.2.0 has insufficient validation of room predecessor links in `MatrixClient::getJoinedRooms`, allowing a remote attacker to attempt to replace a tombstoned room with an unrelated attacker-supplied room.