Today we are retroactively publishing advisories for security bugs in Synapse. From oldest to most recent, they are:

• GHSA-p9qp-c452-f9r7 (CVE-2022-39374), fixed in Synapse 1.68.0 and affecting all prior versions since Synapse 1.62.0;
• GHSA-45cj-f97f-ggwv (CVE-2022-39335), fixed in Synapse 1.69.0 and affecting all prior versions; and finally
• GHSA-f3wc-3vxv-xmvr (CVE-2023-32323), fixed in Synapse 1.74.0 and affecting all prior versions.

We strongly advise Synapse operators who are still on earlier Synapse versions to upgrade to the latest version (v1.84.0) or at the very least v1.74.0 (released Dec 2022), to prevent attacks based on these vulnerabilities. Please see the advisories for the full details, including a description of

• the vulnerability and potential attacks,
• exactly which deployments are vulnerable, and
• workarounds and mitigations.

Because these bugs are either related to or exploitable over Matrix federation, we have delayed publishing these advisories until now out of caution. This allowed us to ensure that the majority of Synapse homeservers across the public federation have upgraded to a sufficiently patched version, based on the (opt-in) stats reporting to the Matrix.org foundation.

If you have any questions or comments about this announcement or any of the advisories, e-mail us at [email protected].

Today we are issuing security releases of matrix-js-sdk and matrix-react-sdk to patch a pair of High severity vulnerabilities (CVE-2023-28427 / GHSA-mwq8-fjpf-c2gr for matrix-js-sdk and CVE-2023-28103 / GHSA-6g43-88cp-w5gv for matrix-react-sdk).

Affected clients include those which depend on the affected libraries, such as Element Web/Desktop and Cinny. Releases of the affected clients should follow shortly. We advise users of those clients to upgrade at their earliest convenience.

The issues involve prototype pollution via events containing special strings in key locations, which can temporarily disrupt normal functioning of matrix-js-sdk and matrix-react-sdk, potentially impacting the consumer's ability to process data safely.

Although we have only demonstrated a denial-of-service-style impact, we cannot completely rule out the possibility of a more severe impact due to the relatively extensive attack surface. We have therefore classified this as High severity and strongly recommend upgrading as a precautionary measure.

We found these issues during a codebase audit that we had previously announced in an earlier security release of matrix-js-sdk and matrix-react-sdk. The earlier release had already addressed a set of similar vulnerabilities that were assigned CVE-2022-36059 / GHSA-rfv9-x7hh-xc32 and CVE-2022-36060 / GHSA-2x9c-qwgf-94xr, which we had initially decided not to disclose until the completion of the audit. Now that the audit is finished, we are disclosing those previous advisories as well.

TL;DR:

• Two critical severity vulnerabilities in end-to-end encryption were found in the SDKs which power Element, Beeper, Cinny, SchildiChat, Circuli, Synod.im and any other clients based on matrix-js-sdk, matrix-ios-sdk or matrix-android-sdk2.
• These have now been fixed, and we have not seen evidence of them being exploited in the wild. All of the critical vulnerabilities require cooperation from a malicious homeserver to be exploited.
• Please upgrade immediately in order to be protected against these vulnerabilities.
• Clients with other encryption implementations (including Hydrogen, ElementX, Nheko, FluffyChat, Syphon, Timmy, Gomuks and Pantalaimon) are not affected; this is not a protocol bug.
• We take the security of our end-to-end encryption extremely seriously, and we have an ongoing series of public independent audits booked to help guard against future vulnerabilities. We will also be making some protocol changes in the future to provide additional layers of protection.
• This resolves the pre-disclosure issued on September 23rd.

Hi all,

Recently we have been hard at work investigating some subtle security vulnerabilities in certain implementations of Matrix's end-to-end encryption which were responsibly disclosed to us by researchers at Royal Holloway University London, University of Sheffield and Brave Software. Two of these vulnerabilities are critical severity, in that they could allow malicious server admins to attack their users, and are implementation bugs in clients using matrix-js-sdk (e.g. Element Web) or implementations derived from matrix-js-sdk, rather than protocol flaws. matrix-rust-sdk (and other 2nd/3rd generation SDKs) are not affected by these. These vulnerabilities are fixed in today's release, and we are not aware of them having been exploited in the wild.

If you're using Element or an application that shares the same SDKs (Beeper, Cinny, SchildiChat, Circuli, Synod.im) then please upgrade now. Do not perform verification with new devices until you have upgraded.

We'd like to thank the security researchers for investing significant time and effort into doing a deep dive to find these issues, and thus contributing materially to making Matrix more secure for the whole ecosystem. Despite our best efforts, there is always a risk of security issues in software, and we're very glad to have identified and fixed these issues while also taking the opportunity to improve our vulnerability disclosure and coordinated upgrade process.

Please note that the critical severity issues are implementation issues in matrix-js-sdk and derivatives, and are not protocol issues in Matrix. The latest version of the researchers' paper that we've seen incorrectly presents Element as 'the reference Matrix client', and confuses the higher severity implementation bugs with lower severity protocol critique. This is very unfortunate, given Hydrogen, ElementX, Nheko, FluffyChat, Syphon, Timmy, Gomuks and Pantalaimon and other independent implementations are not affected. In fact, every client independently implemented using the Matrix spec seems to have got it right, which speaks well of the protocol. It's only the first generation SDK (predating the spec) and its derivatives which had these bugs.

The two critical severity issues lead to three attack scenarios, all of which are prevented by today's releases:

• "Key/Device Identifier Confusion in SAS Verification" – A bug existed in matrix-js-sdk where it confused together device IDs and cross-signing keys (given under the hood, cross-signing keys are represented as devices). This could be exploited by a malicious server admin to break emoji-based verification when cross-signing is in use, authenticating themselves rather than the target user being verified. This bug is only present in matrix-js-sdk (not iOS or Android SDKs), tracked as a critical severity CVE: CVE-2022-39250.

• "Trusted Impersonation" – matrix-js-sdk (and derived SDKs) suffered from a protocol-confusion bug where it would incorrectly accept to-device messages encrypted by Megolm rather than Olm, attributing them to the Megolm sender rather than the actual sender. As a result, an attacker could fake the trusted sender of to-device messages, allowing them to send fake to-device messages to devices - e.g. fake keys to spoof historical messages from other users. This bug is tracked as a critical severity CVE: CVE-2022-39251 (matrix-js-sdk), CVE-2022-39255 (matrix-ios-sdk) and CVE-2022-39248 (matrix-android-sdk2).

• "Malicious key backup" – the above 'trusted impersonation' bug in matrix-js-sdk (and derived SDKs) could be used by a malicious homeserver admin to add a malicious key backup to the user's account under certain unusual conditions in order to exfiltrate message keys. While we are not aware of this being exploited in the wild, out of an abundance of caution we recommend checking your key backup settings. If you are particularly paranoid you may wish to reset your online key backup. This doesn't have a separate CVE, as the root cause is the same as "Trusted Impersonation".

Three lower priority issues were also identified by the researchers:

• "Semi-trusted Impersonation" – matrix-js-sdk (and derived SDKs) accepted keys forwarded by other users, even if your client didn't request them. As a result, a malicious server admin could fake an encrypted message to look as if it was sent from a given user on that server. However, impersonated messages like this are clearly marked by clients like Element with a clear "The authenticity of this encrypted message can't be guaranteed" warning – which is why we consider this low severity. That said, it's an avoidable attack, and we've fixed this by ensuring that clients don't accept 'unsafe' keys (with the exception of keys forwarded when you invite a user to an existing conversation). In future, in Olm/Megolm v2 we're also linking key-sending events to the underlying recipient Olm identity to ensure that keys cannot be misappropriated. This issue is tracked as a moderate severity CVE: CVE-2022-39249 (matrix-js-sdk), CVE-2022-39257 (matrix-ios-sdk) and CVE-2022-39246 (matrix-android-sdk2).

• "Homeserver Control of Room Membership" – A malicious homeserver can fake invites on behalf of its users to invite malicious users into their conversations, or add malicious devices into its users accounts. However, when this happens, we clearly warn the user: if you have verified the users you are talking to, the room and user will be shown with a big red cross to mark if malicious devices have been added. Similarly, if an unexpected user is invited to a conversation, all users can clearly see and take evasive action. Therefore we consider this a low severity issue. That said, this behaviour can be improved, and we've started work on switching our trust model to trust-on-first-use (so that new untrusted devices are proactively excluded from conversations, even if you haven't explicitly verified their owner) - and we're also looking to add cryptographic signatures to membership events in E2EE rooms to stop impersonated invites. These fixes will land over the coming months.

• "IND-CCA break" – Matrix's usage of AES-CTR to encrypt attachments, secrets and symmetric key backups is not "IND-CCA2 secure", because it does not include the AES initialisation vector within the hash used to secure the payload from tampering. As a result, if an attacker could observe the result of both a given encryption and a given decryption operation, it would be possible to extract the encryption private key. However, this is a purely theoretical attack as Matrix does not provide a way to mount the attack. In the future, we will fix our use of AES-CTR to include the IV within the hash.

We'd like to again thank Martin R. Albrecht and Dan Jones from the Information Security Group at Royal Holloway University London, Benjamin Dowling from Security of Advanced Systems Group, University of Sheffield and Sofía Celi from Brave Software for discovering these issues and responsibly disclosing them to us, and then working with us to agree on an extended disclosure window given the amount of work needed to verify and ship fixes throughout Matrix over the course of the summer period. We welcome any further formal security analysis work, and hope that it will distinguish clearly between Matrix-the-protocol and Matrix implementations like matrix-js-sdk, rather than conflating them. You can read their full paper here.

We'd also like to thank all the downstream Element package maintainers, downstream forks and other affected clients for working together under time constraints for this coordinated release - your patience and understanding is very much appreciated indeed.

Meanwhile, we are taking extreme measures to avoid future E2EE vulnerabilities. You will notice that matrix-rust-sdk, hydrogen-sdk and other 2nd and 3rd generation SDKs were not affected by the bugs at the root cause of the critical issues here. This is precisely why we have been working on replacing the first generation SDKs with a clean, carefully written Rust implementation in the form of matrix-rust-sdk, complete with an ongoing independent public audit.

We started the process of auditing matrix-rust-sdk with the Least Authority vodozemac audit in May, and we have three more audits agreed – covering matrix-rust-sdk-crypto, matrix-rust-sdk, and a whole reference Matrix stack. Ironically, the mitigation work for these vulnerabilities in the legacy SDKs has severely impacted our timelines for finishing matrix-rust-sdk-crypto work (in fact, we had to push back the Least Authority audit of matrix-rust-sdk-crypto given the burndown has not progressed), but we will be shifting to the new audited codebase as rapidly as we possibly can.

Over the coming months we will also introduce our first ever major version update of Olm and Megolm, in order to fix the MAC truncation issue highlighted in the vodozemac audit (Issue J), and reduce the risk of further key-forwarding issues (as per the "Semi-trusted Impersonation" vulnerability above). New conversations will default to using v2 of Olm/Megolm for security, and existing conversations can be optionally upgraded (similar to a 'room version' upgrade in Matrix today). We are also adding extensive end-to-end testing using Polyjuice and Traffic Light to stress-test encryption and improve reliability.

Finally, we will continue our research into layering Matrix over Messaging Layer Security (MLS) - the IETF proposed standard for interoperable end-to-end encrypted group messaging. This work has been delayed by the mitigation activity above, but otherwise it's making good progress and we're excited to see how Decentralised MLS performs in reality against Olm+Megolm v2.

We'd like to apologise to the wider Matrix community for the inconvenience and disruption of these issues, and thank you for your patience while we've resolved them.

Matthew, Denis and the Matrix cryptography & security teams.

We will be releasing a security update to matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk2 and clients which implement end-to-end encryption with these libraries, to patch critical security issues, on Wed, Sept 28th. The releases will be published in the afternoon, followed by the disclosure blog post around 16:00 UTC. The affected clients include Element Web, Desktop, iOS and Android. We will also be working with downstream packagers and forks over the coming days to ensure a synchronised release to address affected clients.

Clients using matrix-rust-sdk, hydrogen-sdk and matrix-nio are not affected by these critical issues. We are also auditing third-party client SDKs and clients in advance of the release, and will work with the projects if action is needed. So far we've confirmed that other popular SDK/clients including mtxclient (nheko), Matrix Dart SDK (FluffyChat), Trixnity (Timmy), Syphon, mautrix-go (Gomuks) and mautrix-python are not affected by the issues in question.

If you maintain or package a (potentially) affected E2EE-capable Matrix client and need to coordinate on the release, please contact [email protected].

We advise to upgrade as soon as possible after the patched versions are released.

Thank you for your patience while we work to resolve this issue.

We've released a new version of matrix.org's node-irc 1.3.0 and matrix-appservice-irc 0.35.0, to patch several security issues:

• IRC mode operator confusion (Low, GHSA-cq7q-5c67-w39w)
• Parsing issue leading to room takeovers (High, GHSA-xvqg-mv25-rwvw)
• Undisclosed issue (Moderate, GHSA-r3p6-cg2c-c4qw)

The details of the final vulnerability will be released at a later date, pending an audit of the codebase to ensure it's not affected by other similar vulnerabilities.

The vulnerabilities have been patched in node-irc version 1.3.0 and matrix-appservice-irc 0.35.0. You can get the release on Github.

The bridges running on the Libera Chat, OFTC and other networks bridged by the Matrix.org Foundation have been patched.

Please upgrade your IRC bridge as soon as possible.

The above vulnerabilities were reported by Val Lorentz. Thank you!

Today we are issuing security releases of matrix-js-sdk and matrix-react-sdk to patch a couple of High severity vulnerabilities (reserved as CVE-2022-36059 for the matrix-js-sdk and CVE-2022-36060 for the matrix-react-sdk).

Affected clients include those which depend on the affected libraries, such as Element Web/Desktop and Cinny. Releases of the affected clients will follow shortly. We advise users of those clients to upgrade at their earliest convenience.

The vulnerabilities give an adversary who you share a room with the ability to carry out a denial-of-service attack against the affected clients, making it not show all of a user's rooms or spaces and/or causing minor temporary corruption.

The full vulnerability details will be disclosed at a later date, to give people time to upgrade and us to perform a more thorough audit of the codebase.

Note that while the vulnerability was to our knowledge never exploited maliciously, some unintentional public testing has left some people affected by the bug. We made a best effort to sanitize this to stop the breakage. If you are affected, you may still need to clear the cache and reload your Matrix client for it to take effect.

We thank Val Lorentz who discovered and reported the vulnerability over the weekend.