We are happy to launch The Matrix Conference on Oct 15-18 in Strasbourg, France. Learn more about it, buy a ticket!

Security

43 posts tagged with "Security" (See all categories)

Atom Category Atom Feed

Project Hydra: Improving state resolution in Matrix

2025-08-14 — General, SecurityKegan Dougal, Staff Engineer - Element

Hi all,

On July 16th 2025 we issued a pre-disclosure for vulnerabilities in the federation protocol, and announced new releases of Matrix homeservers on Mon August 11. Today we are ending the embargo and disclosing the remaining MSCs. This post will go into more detail about the changes and what led up to them.

This project has the codename “Hydra” and is an ongoing exercise in improving the security of the federation protocol. Given the security-sensitive nature of this work, it was done under embargo by the backend team at Element, the Matrix.org Security Team, the Spec Core Team, alongside Timo Kösters (who privately reported a related vulnerability, helping jumpstart the project) and Florian Jacob (at Karlsruher Institut für Technologie). The work was subsequently shared, reviewed and MSC’d under embargo with maintainers of all known Matrix homeserver implementations which implement State Resolution 2.0 on June 13th, so they could prepare for the coordinated release on August 11. We have then given server admins 3 more days to upgrade before lifting the embargo and disclosing the vulnerability details here.

This entire process has been highly unusual for the ecosystem, and it’s unfortunate that we were unable to make these changes out in the open. Where possible, we moved to release redacted versions of the MSCs as soon as we were comfortable from a security perspective (e.g. releasing MSC4289 and MSC4291 ahead of time, with redacted sections). Furthermore, we’d like to apologise for the disruption in landing a new stable room version and specification release with immediate effect rather than allowing for a period of public review. Going forwards, normal MSC work will continue in public as it ever has, along with normal on-cycle specification releases.

Continue reading…

Security Release

2025-08-11 — SecurityJim Mackenzie, VP Trust & Safety — The Matrix.org Foundation

Hi all,

Last month we issued a Pre-disclosure: Upcoming coordinated security fix for all Matrix server implementations, describing a coordinated release to fix two high severity protocol vulnerabilities (CVE-2025-49090; the other not yet allocated a CVE). That release is now available as of 17:00 UTC on August 11, 2025. Server updates are now available, and MSCs & spec updates will follow on Thursday, August 14, 2025, bringing us to version 1.16 of the spec later in the month, and introducing room version 12.

Continue reading…

Pre-disclosure: Upcoming coordinated security fix for all Matrix server implementations

2025-07-16 — General, SecurityMatthew Hodgson

Hi all,

Over the last 6 months a major project has been underway by the Element server team and the Matrix.org Foundation security team to investigate “state resets”: scenarios where Matrix’s state resolution algorithm can give unexpected results. As part of this work we’ve identified two high severity protocol vulnerabilities (CVE-2025-49090; the other not yet allocated a CVE).

Given the security implications of a federation protocol vulnerability, we’ve shared details under embargo over the last 4 weeks with all known active server implementations, and are now aiming for a coordinated security release across all Matrix server implementations on Tuesday Jul 22nd Monday Aug 11th 2025 at 17:00 UTC. If you run a Matrix server in an untrusted federation (e.g. the public federation), please be prepared to upgrade as soon as the patched versions are available.

These vulnerabilities have been addressed via MSCs which have been shared, reviewed and are in the final comment period (disposition merge) with the Spec Core Team and server implementor community, under embargo. This will result in an off-cycle Matrix spec release (1.16) introducing a new room version (12) to address the vulnerabilities in question, requiring a room upgrade of existing rooms. Having given server and room admins time to upgrade, we are then planning to un-embargo the MSCs and complement tests on Friday Jul 25th Thursday Aug 14th 2025 at 17:00 UTC.

UPDATE: Jul 18th 16:45 UTC: We've heard a lot of feedback that 6 days isn't enough for clients/bots/bridge/tooling developers to test the changes introduced by room v12, and that it also doesn't give enough time for community admins to prepare for the necessary room upgrades. Underestimating the time needed here for client/community testing is entirely our fault, due to being overfocused on coordinating the significant serverside work needed. As a result, we've pushed back the coordinated server release date to Aug 11th, to give everyone more time to test and prepare. We've also opened up registration on the beta.matrix.org homeserver, which is already running v12 rooms by default, to make it easier for client developers to test their clients. We've also made one clarification below for client developers, explaining the new permissions needed to send m.room.tombstone events.

CLARIFICATION: Jul 16 17:30 UTC: Room admins should plan to upgrade rooms at their convenience, similar to previous security-related room version upgrades (e.g. v1 to v2). Much like installing an operating system patch, sooner is better, but as these are not Critical Severity vulnerabilities, there is no requirement for room admins to upgrade rooms immediately on Jul 22nd. For instance, the Matrix.org Foundation will likely upgrade its public rooms at some point after Jul 25th (having given server admins a chance to upgrade, and having given any server implementations running late a chance to release). N.B. Only rooms which include users on potentially malicious servers (e.g. publicly joinable rooms on untrusted federations) are vulnerable.

Important information for client developers:

  • Client developers should review MSC4291: “Room IDs as hashes of the create event” to ensure their clients can accept the new proposed format of room IDs, and no longer expects content.predecessor.event_id in m.room.create events.

  • One of the other changes coming in v12 is that room creators will be privileged over other users in the room. Therefore clients which restrict user behaviour based on power level will need to be updated to be aware that room creators effectively have infinite power level. Creators are not listed in the users block of the m.room.power_levels event, and are instead defined as the sender field of the m.room.create event, or entries in a new optional additional_creators array field in the content of the create event. Full details will be released in the MSCs when embargo lifts.

  • Finally, clients which use power_level_content_override when creating rooms MUST NOT assign a power level to the room creator, otherwise the /createRoom request will fail.

  • UPDATE: Jul 18th: We should have mentioned that the default power level in room v12 for sending m.room.tombstone events to upgrade rooms is 150. This stops normal admins from upgrading the room (and so assuming creator privileges) - instead, a creator has to explicitly boost an admin's power level to 150 in order to let them upgrade the room and effectively assume creator rights going forwards.

This has been an exceptionally complicated project to coordinate and its security implications required us to deviate from our usual MSC process and develop the changes under embargo. This and the expedited release of a new stable room version are exceptional choices that are far from ideal, which we’re having to take to keep the ecosystem secure. To be clear, normal MSC development and process will continue in the open, just as it always has. We’d like to sincerely thank the Matrix server implementor community for their impressive support in preparing the coordinated security releases - both in terms of vital MSC review, and then working together to implement the necessary changes. Matrix’s server heterogeneity has never looked healthier. We’d also like to thank Timo Kösters for helping precipitate the project in the first place.

We’ll follow up with more details on Aug 11th (assuming the disclosure timeline doesn’t slip further).

Thanks all for your time, patience and understanding while we ship this protocol upgrade (the first coordinated upgrade since Matrix 1.0 back in 2019!)

Matthew

Security disclosure for matrix-js-sdk (CVE-2024-47080) and matrix-react-sdk (CVE-2024-47824)

2024-10-15 — SecurityMatrix.org Security Team

Hi all,

We are disclosing two high-severity vulnerabilities in matrix-js-sdk and matrix-react-sdk related to MSC3061, which specifies sharing room keys with newly invited users for message history access.

🔗Affected versions

🔗Vulnerability details

When inviting a user to an encrypted room, in the legacy (pre-Rust) encryption implementation, matrix-react-sdk forwarded existing message keys to the newly invited user so they could decrypt shared message history as per MSC3061. The implementation is provided by matrix-js-sdk, which incorrectly applied the same rules for sending existing keys to the invited user as for sending new keys, which allows them to be sent to unverified devices and unverified users. While there's always some risk of key exposure to a server-side attacker when you're interacting with unverified users, the risk is higher for historical keys.

🔗Root cause and remediation

The root cause of the matrix-react-sdk vulnerability is a function call into vulnerable functionality implemented in the matrix-js-sdk. The matrix-react-sdk vulnerability was addressed earlier, in matrix-react-sdk version 3.102.0, by removing the call. The matrix-js-sdk vulnerability will be addressed in version 34.8.0 to remove the vulnerable functionality completely. Because of these differences, two separate advisories were warranted.

Note that the vulnerability is only present in the matrix-js-sdk when running the old, non-Rust encryption stack. The vulnerable functionality was never implemented in the Rust-based stack. As a result, clients using the matrix-js-sdk in Rust crypto mode (i.e. calling initRustCrypto rather than initCrypto) are not vulnerable, even if on a nominally vulnerable version.

Furthermore, matrix-android-sdk2 and matrix-ios-sdk have similar functionality that is gated behind an experimental setting—we recommend avoiding use of this setting, though there are no specific advisories since the feature has only been available in an experimental state.

🔗Proposed specification changes

To fix this functionality in terms of the specification process, we will open an MSC to explicitly clarify that MSC3061 key forwarding should only forward keys to verified devices owned by verified users, ensuring that historical keys are never shared with untrusted devices. This also encourages users to verify each other to enable reading message history, thereby improving Matrix security against interception.

🔗Note on project ownership

The matrix-react-sdk is no longer a Foundation project but that of Element and has been moved to https://github.com/element-hq/matrix-react-sdk. However, the vulnerability in question was introduced, found and patched while it was still under Foundation ownership. For this reason, the Matrix.org Security team decided to treat this as a Foundation advisory. Future advisories for matrix-react-sdk (if any) will come from Element.

Disclosure: Bridges security issues

2023-08-04 — Bridges, SecurityIntegrations Team, Matrix Security Team

Hi folks. As previously mentioned on Monday, we’re now disclosing the vulnerabilities patched for the IRC, Slack and Hookshot bridges. If you have not already done so, please ensure you are running the patched versions.

Today we are disclosing the 3 vulnerabilities.

🔗matrix-appservice-bridge doesn't verify the sub parameter of an openId token exchange (CVE-2023-38691)

GHSA-vc7j-h8xg-fv5x / CVE-2023-38691

The POST /v1/exchange_openid endpoint did not check that the servername part of the sub parameter (containing the user's claimed MXID) is the same as the servername we are talking to. This could allow a malicious actor to spin up a server on any given domain, respond with a sub parameter according to the user they want to act as and use the resulting token to perform provisioning requests.

This is now patched so that the server part of the sub / user ID is checked against the server used to make the request.

Discovered and reported by a community member.

🔗IRC command injection via admin commands containing newlines (CVE-2023-38690)

GHSA-3pmj-jqqp-2mj3 / CVE-2023-38690

When the IRC bridge attempted to parse an admin command from a Matrix user, it would only split arguments by a literal space. For example, sending “!join #matrix\nfoobar” would treat the channel name as “#matrix\nfoobar”. This could then be exploited to inject any IRC command into the bridge to be run. Since the !join command first joins via the bridge bot user, it could be used to execute commands as the bridge bot.

This is now patched so that both the command handler is more strict about its arguments, as well as channel names being explicitly validated when provided by users.

Discovered and reported by Val Lorentz.

🔗Events can be crafted to leak parts of targeted messages from other bridged rooms (CVE-2023-38700)

GHSA-c7hh-3v6c-fj4q / CVE-2023-38700

The IRC bridge caches recent timeline messages in memory, so that when a reply is seen for a message it doesn’t need to request the event content from the homeserver. However the room ID was not validated when accessing this cache, so a malicious actor could craft a reply event in another room referencing any event ID (so long as it was still in the bridge cache) to trick the bridge into posting the message content into a bridged reply.

Discovered and reported by Val Lorentz.

If you have further questions, please reach out on [email protected]

Bridges Security Update

2023-07-31 — Bridges, SecurityIntegrations Team, Matrix Security Team

Today we are announcing security updates for several of our bridges.

In addition we have released matrix-appservice-bridge 9.0.1 (and backported to 8.1.2) which patches GHSA-vc7j-h8xg-fv5x.

All mentioned bridges are affected by a vulnerability in the provisioning interfaces of these bridges. If you are unable to upgrade, please disable provisioning for now (which should be documented in the relevant bridge sample config).

Continue reading…

Postponing the Libera.Chat deportalling

2023-07-28 — Bridges, SecurityThib

We have recently announced that we will be honouring Libera Chat’s request to turn off portalled rooms on the Libera.Chat bridge maintained by the Matrix.org Foundation. The changes were originally scheduled to be effective on 31st July. In the meantime, we posted instructions for people to turn their portalled rooms into plumbed ones so the bridge keeps working for them.

Some stability issues on the bridge have prevented people from turning their portalled rooms into plumbed ones. We have been actively working on resolving those issues since the first reports and the situation is gradually improving. However, at this point, we do not believe the plumbed mode can be considered sufficiently stable yet.

Continue reading…

Disclosing Synapse security advisories

2023-05-24 — SecurityDenis Kasak
Last update: 2023-05-24 13:36

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

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].

Security releases: matrix-js-sdk 24.0.0 and matrix-react-sdk 3.69.0

2023-03-28 — Releases, SecurityDenis Kasak

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.

Upgrade now to address E2EE vulnerabilities in matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk2

2022-09-28 — SecurityMatthew Hodgson, Denis Kasak, Matrix Cryptography Team, Matrix Security Team

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.

Continue reading…