Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact 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. Patches The issue has been patched and users should upgrade to 38.2.0. Workarounds Avoid using MatrixClient::getJoinedRooms in favour of getRooms() and filtering upgraded rooms separately.
Recommended action: Upgrade to 38.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 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
Recommended action: Upgrade to 34.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 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…
Recommended action: Upgrade to 34.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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) 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.
Recommended action: Upgrade to 34.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker present in a room where an MSC3401 group call is taking place can eavesdrop on the video and audio of participants using matrix-js-sdk, without their knowledge. To affected matrix-js-sdk users, the attacker will not appear to be participating in the call. This attack is possible because matrix-js-sdk's group call implementation accepts incoming direct calls from other users, even if they have not yet declared intent to participate in the group call, as a means of resolving a race condition in call setup. Affected versions do not restrict access to the user's outbound media in this case. Legacy 1:1 calls are unaffected. Workarounds Users may hold group calls in private rooms where only the exact users who are expected to participate in the call are present.
Recommended action: Upgrade to 24.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In certain configurations, data sent by remote servers containing special strings in key locations could cause modifications of the Object.prototype, disrupting matrix-js-sdk functionality, causing denial of service and potentially affecting program logic. (This is part 2, where CVE-2022-36059 / GHSA-rfv9-x7hh-xc32 is part 1. Part 2 covers remaining vectors not covered by part 1, found in a codebase audit scheduled after part 1.) Patches The issue has been patched in matrix-js-sdk 24.0.0. Workarounds None. References - Release blog post - The advisory GHSA-rfv9-x7hh-xc32 (CVE-2022-36059) refers to an initial set of vulnerable locations discovered and patched in matrix-js-sdk 19.4.0. We opted not to disclose that advisory while we performed an audit of the codebase and are now disclosing it jointly with this one. For more information If you have any questions or comments about this advisory please email us at security at matrix.org.
Recommended action: Upgrade to 24.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Events sent with special strings in key places can temporarily disrupt or impede the matrix-js-sdk from functioning properly, potentially impacting the consumer's ability to process data safely. Note that the matrix-js-sdk can appear to be operating normally but be excluding or corrupting runtime data presented to the consumer. Patches This is fixed in matrix-js-sdk 19.4.0. Workarounds Redacting applicable events, waiting for the sync processor to store data, and restarting the client can often fix it. Alternatively, redacting the applicable events and clearing all storage will often fix most perceived issues. In some cases, no workarounds are possible. References https://learn.snyk.io/lessons/prototype-pollution/javascript/ For more information If you have any questions or comments about this advisory please email us at security at matrix.org.
Recommended action: Upgrade to 19.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 19.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. These attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm. Patches matrix-js-sdk has been modified to only accept Olm-encrypted to-device messages. Out of caution, several other checks have been audited or added: - Cleartext m.roomkey, m.forwardedroomkey and m.secret.send todevice messages are discarded. - Secrets received from…
Recommended action: Upgrade to 19.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker cooperating with a malicious homeserver can construct messages appearing to have come from another person. Such messages will be marked with a grey shield on some platforms, but this may be missing in others. This attack is possible due to the matrix-js-sdk implementing a too permissive key forwarding strategy on the receiving end. Key forwarding is a mechanism allowing clients to recover from “unable to decrypt” messages when they missed the initial key distribution, at the time the message was originally sent. Examples include accessing message history before they joined the room but also when some network/federation errors have occurred. Patches The default policy for accepting key forwards has been made more strict in the matrix-js-sdk. matrix-js-sdk will now only accept forwarded keys in response to previously issued requests and only from own, verified devices. A unique exception to this rule is with the experimental MSC3061, that is forwarding room keys for…
Recommended action: Upgrade to 19.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Improperly formed beacon events (from MSC3488) can disrupt or impede the matrix-js-sdk from functioning properly, potentially impacting the consumer's ability to process data safely. Note that the matrix-js-sdk can appear to be operating normally but be excluding or corrupting runtime data presented to the consumer. Patches This is patched in matrix-js-sdk v19.7.0 Workarounds Redacting applicable events, waiting for the sync processor to store data, and restarting the client can often fix it. Alternatively, redacting the applicable events and clearing all storage will fix the further perceived issues. Downgrading to an unaffected version, noting that such a version may be subject to other vulnerabilities, will additionally resolve the issue. References N/A - This was a logic error in the SDK. For more information If you have any questions or comments about this advisory please email us at security at matrix.org.
Recommended action: Upgrade to 19.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A logic error in the room key sharing functionality of matrix-js-sdk before 12.4.1 allows a malicious Matrix homeserver† participating in an encrypted room to steal room encryption keys from affected Matrix clients participating in that room. This allows the homeserver to decrypt end-to-end encrypted messages sent by affected clients. † Or anyone with access to the account of the original recipient of an encrypted message. Known clients affected (via their use of vulnerable versions of matrix-js-sdk): - Element Web (1.8.2 and earlier) - Element Desktop (1.8.2 and earlier) - SchildiChat Web (1.7.32-sc1 and earlier) - SchildiChat Desktop (1.7.32-sc1 and earlier) - Cinny (1.2.0 and earlier) Patch This was fixed in https://github.com/matrix-org/matrix-js-sdk/commit/894c24880da0e1cc81818f51c0db80e3c9fb2be9. Workarounds To prevent a homeserver from being able to steal the room keys, vulnerable clients can be taken offline or signed out. If signing out, care should be taken to either…
Recommended action: Upgrade to 12.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.