Matrix.org - Security

Analysis of reported issues in vodozemac

2026-02-18T21:21:47+00:00

Today a blog post</a> was published alleging a series of vulnerabilities in Matrix's vodozemac cryptographic library. The post follows a private disclosure to security@matrix.org</a>. While we prefer coordinated disclosure, the author chose to publish prior to further technical discussion, including clarification of the claimed severity.</p>

We take cryptographic concerns seriously and welcome scrutiny of our cryptographic protocols and implementations. However, we disagree with several conclusions in the post regarding exploitability and impact to Matrix deployments. Below we analyse the claims in terms of realistic attacker capabilities and protocol invariants.</p>

🔗</a>Executive summary</h2>

We confirm the Olm 3DH code path in vodozemac doesn't currently reject all-zero X25519 outputs.</li>
We disagree with the post's claim that this leads to any loss of confidentiality in Matrix, let alone complete loss.</li>
Olm v2 is neither standardised nor deployed in today's Matrix. Claims framed as downgrades are about experimental future configuration, not the current spec.</li>
Olm v1 uses truncated 64-bit message authentication tags, a remnant of an earlier time when Matrix's cryptography was closely following Signal's. We acknowledge this as a trade-off and that using longer authentication tags would provide a larger security margin, as has been publicly documented in a previous audit of vodozemac</a>.</li>
Nevertheless, truncated 64-bit message authentication tags remain a common trade-off in deployed messaging systems and we do not consider this a practically exploitable vulnerability. For example, Signal also uses 64-bit message authentication tags</a>.</li>
The "Miscellaneous Issues" are a mix of UX mechanisms being misinterpreted as cryptographic checks (e.g. the CheckCode) and observations without demonstrated security impact.</li>
In summary, we believe the post does not describe any practically exploitable vulnerabilities.</li> </ul>
The central claim of the blog post is that an attacker can read Matrix users' conversations. That claim requires an attacker to cause two honest clients to derive the same predictable session key. The post does not demonstrate a path to achieve this under Matrix's authenticated key distribution model.</p>
🔗</a>Issue analysis</h2>
🔗</a>Olm Diffie-Hellman Accepts the Identity Element</h3>
The claim in the title is accurate and not disputed (with some imprecision in terminology: the all-zero Montgomery `u</code> encoding does not represent the curve's identity element). vodozemac's X25519 Diffie-Hellman method does not currently reject computations involving the all-zero input nor indeed any of the small-order subgroup elements, neither via direct validation of the input points nor via the rejection of the all-zero Diffie-Hellman output.</p>`
`What we dispute is the later impact claim, that this leads to a complete loss of Olm and Matrix room confidentiality. That conclusion does not follow under Matrix's authenticated key distribution model.</p>`
`The core claim is that an attacker can cause both parties to derive a predictable session key by introducing a low-order public key input into the 3DH computation.</p>`
`In Olm's 3DH, the session key is derived from three Diffie-Hellman outputs:</p>`
`DH(ia, EB)</code></li> DH(ea, IB)</code></li>`
DH(ea, EB)</code></li> </ul> where ia</code>/IB</code> are long-term identity keys and ea</code>/EB</code> are pre-keys. Lowercase denotes private keys; uppercase denotes public keys.</p> For an attacker Mallory to force a predictable session key known to her, she must cause both Alice and Bob to derive identical, attacker-controlled outputs for all three DH computations.</p> In Matrix, the identity key and pre-keys are authenticated via signatures from the device's long-term Ed25519 identity key. Clients verify these signatures before establishing a session. Therefore, a network attacker cannot substitute low-order public keys for those inputs.</p> Consequently, under Matrix's authenticated key distribution model, the described behavior does not yield a confidentiality break between two honest clients.</p> That said, in our brief correspondence with the reporter, after outlining our position and asking for clarification or a sketch of an actual attack, we agreed to add the check as a defence-in-depth and to preempt future doubt about whether this is a vulnerability. We also noted the possibility of vodozemac being used outside the context of Matrix, acknowledging this should at the very least be documented. We did not receive further technical clarification before publication.</p>
The post argues that references to RFC 7748 and Trevor Perrin are misplaced because they concern the Diffie-Hellman primitive rather than protocols. We disagree with this reading. RFC 7748 makes the all-zero output check optional at the primitive level and explicitly notes that protocol designers must consider whether contributory behavior is required. Perrin's discussion similarly distinguishes between "safe" and "unsafe" DH protocols, defining safe protocols as those that authenticate peer keys before use. Notably, even Signal `only recently</a> added an explicit all-zero X25519 output check, about a week prior to this post.</p>`
`Matrix's Olm handshake authenticates identity keys and pre-keys via device signatures prior to session establishment. In that context, contributory behavior is not relied upon for protection against active network attackers.</p>`
🔗</a>Downgrade Attacks From V2 to V1</h3> Olm V1</a> is the only currently specified Olm version. The Olm V2 implementation in vodozemac is an experimental implementation of an anticipated future version that has not yet been specified. Given that there is only one standardised version, downgrades are not a current concern and we have not attempted to guard against them. Version negotiation and downgrade resistance become relevant once multiple versions are specified and deployed.</p> 🔗</a>ECIES CheckCode Has Only 100 Possible Values</h3> The claims in this section stem from a misunderstanding of the purpose of the check code, which is purely a UX feature, not a cryptographic check.</p> Since the security of QR code login relies on the user correctly confirming on their secondary device that their primary device is signalling success, we thought it would be unwise to simply ask the user about this in yes/no form. Such a design would carry too large of a risk that the user will simply click through without understanding what is asked.</p> The check code serves as an action requiring higher engagement from the user, slowing them down and forcing them to replicate what they see. The actual information being transferred is only a single bit: success or failure. The slight bias in the digits is therefore irrelevant.</p> 🔗</a>Message Keys Silently Dropped After MAX_MESSAGE_BYTES</code></h3> Vodozemac hard-codes a constant, MAX_MESSAGE_BYTES</code> to equal 40. After more than 40 skipped messaged keys are buffered, any additional keys are silently discarded, making corresponding messages permanently undecryptable.</p> </blockquote> The constant referred to in the post as MAX_MESSAGE_BYTES</code> is in fact MAX_MESSAGE_KEYS</code>. This number controls the largest difference in message indices that can be successfully received out-of-order within a given receiving chain. So for example, if one side sends 50 messages in a row, before receiving any message from the other side, and these messages arrive significantly out of order, such that message 49 arrives first, then we will fail to decrypt message 2, but will still be able to decrypt message 50. The number was chosen empirically, based on typical network conditions. This is not a significant source of undecryptable messages.</p> Similarly, MAX_MESSAGE_GAP = 2000</code> is a hard limit on the message index jump that we will even attempt to decrypt, and again chosen empirically. For example, if we receive message 1 and then message 2100, we will refuse to decrypt it since it is deemed to be too large of a jump at once.</p> 🔗</a>Pickle Format Uses Deterministic IV</h3> As noted by the reporter, this is merely a sharp edge in the API to support legacy pickles and has no security impact. Client applications only ever use this key to encrypt a single pickle and never reuse it.</p> 🔗</a>#[cfg(fuzzing)]</code> Bypasses MAC and Signature Verification</h3> This has already been retracted by the reporter.</p> 🔗</a>Strict Ed25519 Verification is Disabled By Default</h3> This is a trade-off between compatibility and additional protection from signature malleability, which in our usage does not lead to a practical exploit scenario. The reason it's a compatibility trade-off is that RFC 8032, the EdDSA RFC, specifies a looser validation than ed25519-dalek</code>'s strict-signatures</code>. See point 3 in https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.7</a>.</p> The reporter did not report this finding in his latest report, but when he did in 2024, we asked what attack scenario he had in mind. In his own words</a></p> This is almost certainly a no-impact finding (or low-impact at worst), but still an annoying one to see in 2024.</p> </blockquote> If any new information to the contrary has come to light, we are open to reevaluating this.</p> 🔗</a>On the timeline</h2> In his timeline, the reporter notes:</p> 2026-02-17: I respond to Matrix.org with an additional PoC, a patch, and express disagreement with their reasoning</p> </blockquote> We did not receive the referenced additional response prior to publication of the reporter's blog post. Our response was sent at 22:19 UTC while the blog post was published no later than 23:47 UTC.</p> Updated 2026-02-21</strong>: The referenced response, sent at 23:28 UTC, was discovered to have been caught by a spam filter. Thanks to Gnuxie for working with us and the reporter to resolve this.</p> 🔗</a>Closing words</h2> In summary, Matrix's threat model relies on authenticated key distribution: identity keys and pre-keys are signed by device keys and verified prior to session establishment. This prevents a network adversary from substituting non-contributory public keys to force a predictable shared secret between honest clients. The absence of an all-zero check does not compromise this.</p> It's worth saying that in our private correspondence with the reporter we agreed to add the check as a defence-in-depth and to remove any doubt of whether this constitutes a vulnerability. The check will be added in a future vodozemac release.</p> We regret that the public post was published without engaging on the technical questions we raised. Coordinated disclosure works best when both parties explore exploitability in good faith.</p> 🔗</a>Reply to the reporter</h2> Attached below is our verbatim response to the reporter, which was sent shortly before the publication of their blog post:</p> Hi Soatok,</p> We've now completed our assessment of your report. Taking each issue in turn:</p> Olm mishandles the identity element</li> </ol> Your PoC correctly demonstrates that the Olm 3DH implementation in vodozemac does not currently perform the all-zero DH output check. As we're sure you're aware, the check for contributory behaviour in X25519 is a contentious topic among cryptographers, with some calling for it, but others like RFC 77481</a> calling it optional or even arguing against it (e.g. Trevor Perrin2</a>). We've previously considered adding it but ultimately avoided it due to the conclusion that there's no practical security impact on Matrix. In other places like SAS/ECIES we explicitly reject non-contributory outputs because those handshakes can be used in unauthenticated contexts where an all-zero DH output could</em> directly collapse channel security.</p> To sketch out an argument, it's helpful to consider two possible cases of where it might matter. One, an active attacker, Mallory, trying to manipulate a handshake between two honest parties Alice and Bob. Two, a dishonest participant, Malice, taking the place of Bob.</p> In the first case, the handshake is protected from Mallory on the Matrix level, by the fact that Matrix requires all key inputs used in the Olm 3DH handshake (except for the "base key") be signed by the long-term Ed25519 identity keys of the participants. Inbound session establishment is only accepted when the sender identity key matches a signature-verified device key for the claimed sender, and outbound uses signature-verified key bundles.</p> Thus, a third party like Mallory cannot replace any of the bundle keys (the X25519 identity key or the signed pre-key, be it an OTK or the fallback key). The only key that can be replaced is the base key Ea (i.e. Alice's ephemeral "base" key, assuming Alice is the one opening a channel with Bob) which, if replaced with a small order subgroup element, would result in an all-zero DH(Ib, Ea) output on Bob's side. But even then, the attacker cannot influence the corresponding term on Alice's side, so Alice and Bob would still derive different shared secrets and therefore the session would not be viable.</p> The second case is outside our threat model, given that Malice doesn't gain any additional advantage from using this attack compared to the things she can already do by virtue of being one of the conversation endpoints.</p> We believe this covers all threat scenarios relevant for Matrix. If our reasoning is flawed and you see a practical attack, can you please sketch it out?</p> That said, given that vodozemac could potentially be used outside the context of Matrix, we will consider adding the all-zero DH output rejection check in the 3DH path as a defence-in-depth. As a nice side effect, this stops further confusion on whether this is an issue and makes X25519 handling consistent across the entire crate. At the very least, the behaviour should be documented so the user can make an informed decision.</p> 2, 3, and 4. Olm v1 vs v2</p> Olm v1 is the version of the protocol currently standardised by the Matrix specification. Olm v2 is a planned future upgrade that hasn't yet gone through the specification process. The implementation in vodozemac is there so that we are ready for when it does.</p> That there is no configuration knob for controlling the required version via policy is a fair observation. We are already aware of this and are planning to add such a mechanism once Olm v2 is specced and deployed. Given this, vodozemac defaulting on v1 is intentional.</p> Regarding specifically the pickle downgrade attack, there is no version of vodozemac that supports v2 sessions that also omits the config field from the SessionPickle</code>, so a v2 session pickle without a config field cannot arise in an honest setting. It could be constructed maliciously, but what would the attacker gain from this? Once a future version of vodozemac supports policy-enforced minimal session versions, we will consider dropping support for old pickles without a config field and may start rejecting them.</p> In terms of timelines, we follow coordinated disclosure because fixes in the Matrix ecosystem often require changes across multiple implementations and release cycles. We disagree with the characterisation that the response time for your last report was "squandered". In general, we ask reporters to follow our Security Disclosure Policy.</p> That said, based on our current assessment, we do not believe the issues described have a practical security impact for Matrix deployments. We are therefore not requesting an extension and we do not object to publication on 2026-02-18.</p> However, if you believe your report does result in a concrete high-severity attack on Matrix, please share a brief attack sketch (attacker capabilities, prerequisites, and expected impact). If that changes the severity assessment, we will prioritize a fix and coordinate an ecosystem release accordingly.</p> Once again, we thank you for your continued research of the Matrix protocol and software stack.</p> Best regards,</p> Matrix.org Security Team</p> </blockquote>



Project Hydra: Improving state resolution in Matrix
2025-08-14T00:00:00+00:00
Hi all,</p>
On July 16th 2025 we issued a pre-disclosure</a> for vulnerabilities in the federation protocol, and announced new releases</a> 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.</p>
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.</p>
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</a> and MSC4291</a> 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.</p>
</span>
🔗</a>Key Information</h2>
The MSCs added under embargo were:</p>

MSC4289</a>: Explicitly privilege room creators</li>
MSC4291</a>: Room IDs as hashes of the create event, which resolves CVE-2025-54315</a></li>
MSC4297</a>: State Resolution v2.1, which resolves CVE-2025-49090</a></li>
MSC4304</a>: Room Version 12</li>
</ul>
Supporting these MSCs are:</p>

Server-agnostic Complement tests</a></li>
The specification PR introducing room version 12</a></li>
The implementor’s guide to State Res 2.1</a></li>
Creator power level in room version 12</a></li>
</ul>
These changes fixed the following vulnerabilities:</p>

CVE-2025-49090</a>: The Matrix State Resolution algorithm before version 2.1 exhibits undesirable behavior in certain edge conditions, resulting in state resets: the scenario of a room's state resetting to an earlier or incorrect state in the absence of revocation events that would validly result in that state. This allows a malicious participating homeserver to potentially corrupt a room's state by sending a crafted sequence of Matrix events and API responses. Room version 12 resolves the issue by switching to State Resolution v2.1</li>
CVE-2025-54315</a>: Matrix rooms before version 12 do not strongly (i.e. cryptographically) enforce the uniqueness of a room's creation event. While mitigating mechanisms exist which prevent exploitation of the issue in practice, this is a protocol soundness issue. Matrix room version 12 fixes this by making the room ID equal to the hash of the room's creation event.</li>
</ul>
🔗</a>Impact</h2>
These issues only affect servers which are federating with untrusted or potentially malicious servers, such as participating in the public Matrix network.  Servers which are not federated, or which federate in private trusted networks such as BwMessenger, Tchap or TI-Messenger are not affected.</p>
The impact of these issues is rated as ‘high’ rather than ‘critical’ as they do not result in data compromise or exposure. Instead, the risk here is of a malicious homeserver operator corrupting the chatroom’s state by resetting it to a prior value (e.g. reverting access control or room membership to an earlier configuration). This does not</strong> expose conversation history nor any additional data.
We are not aware of these issues being exploited, but would recommend server admins to upgrade immediately if they are operating rooms with users participating from untrusted servers, as per Monday’s announcement</a>. Room admins should then upgrade such rooms to version 12 to guard against these attacks in future - see the new room upgrade guide</a>.</p>
🔗</a>Summary of changes</h2>
This project has resulted in four new Matrix Spec Change proposals to the protocol. At high level, these are:</p>
MSC4289</a>: “Explicitly privilege room creators”. This makes explicit the fact that room creators have 'infinite' power level. The reason we've done this is because in practice the creator’s server can already effectively control a room by backdating events: access control requires a hierarchy, and the creator is at the top of this hierarchy.  This also adds the concept of multiple creators, to avoid control of rooms being centralised on a single server, and to support rooms where ownership genuinely needs to be shared between multiple users (e.g. DMs).  It’s worth noting this does not</em> impact decentralisation – the creators can still sit on multiple servers, and the room itself is replicated equally over participating servers.  Instead, it’s just recognising that access control requires someone to be at the top of the hierarchy, and that person is the room creator.  Separately, we’re looking at approaches to prevent backdating in general by adding ‘finality’ to Matrix.</p>
This MSC also solves the age-old problem</a> where admins could lose control of their own rooms by promoting other users to admin or demoting themselves: now, the creator can always fix such situations. If creators go rogue or disappear, the solution is to establish a new creator by either upgrading the room or creating a new one. Given whoever upgrades a room becomes its new creator, we've changed the default power level needed to upgrade a room to be 150, referred to as 'owner' power level. This allows the room creator to effectively delegate permission to upgrade the room (and so become the new creator) to specific admins by explicitly giving them power level 150.</p>
MSC4291</a>: “Room IDs as hashes of the create event”. This changes the format of room IDs so that they are literally the same as the event ID of the create event. This is a precautionary measure to prevent a potential theoretical class of attacks where malicious server admins could try to introduce false m.room.create events into a room in order to hijack it.</p>
MSC4297</a>: “State Resolution v2.1”.  This is an incremental change over the current State Resolution 2.0 algorithm, which protects against various classes of 'state resets', where delayed federation traffic could cause key-value state associated with a room to revert to an earlier state. This caused symptoms such as users being re-added into a room they have left, or the server no longer recognising users as being present in a room, or access control resetting to a previous state. The new algorithm works by changing the starting state on top of which conflicting events are replayed and it replays more events than previously (replaying not just the conflicted events but all the events in between any two conflicted events—the conflicted state subgraph). This fixes state resets observed in the rooms including: #rust, the Office of the Matrix.org Foundation, the TWIM room, Techlore and Furrytech.</p>
MSC4304</a>: “Room Version 12”. This simply defines the combination of the previous 3 MSCs as room version 12.</p>
For full technical details, please read the actual MSCs: MSC4289</a>, MSC4291</a>, MSC4297</a> and MSC4304</a>.</p>
🔗</a>History</h2>
Matrix optimistically applies changes to room state without waiting for all servers to achieve consensus. This means that sometimes servers will update the room state (e.g. modify the room name) while concurrently, they lose their permission to set said room state (e.g. the user changing the room name is banned). When this happens, the room name change gets rolled back to its previous value. Counterintuitively this can happen even when there is no specific event that causes the user to lose their permission to set room state. This unexpected class of rollbacks is called a “state reset”.</p>
Work on fixing known cases of state resets in the current State Resolution 2.0 algorithm began in 2022 when David Robertson</a> on Element’s backend team investigated known occurrences of the problem that were happening on the public network. He made good progress on identifying the root causes of these occurrences, resulting in the State Resolution v2.1 algorithm. Unfortunately, lack of funding</a> meant work had to be paused. (N.B. if your organisation is operationally dependent on Matrix’s security, please</strong> contribute financially by joining the Foundation as a member</a> in order to fund security work like this.)</p>
The project was then resumed at the end of 2024 as part of a general security review by Element’s backend team and the Matrix Foundation security team which ultimately resulted in MSC4297</a>. Broadly speaking, State Resolution v2.1 makes two changes: it changes the starting state on top of which conflicting events are replayed and it replays more events than previously (replaying not just the conflicted events but all the events in between any two conflicted events—the conflicted state subgraph</em>). This fixes state resets observed in public rooms including: #rust, the Office of the Matrix.org Foundation, the TWIM room, Techlore and Furrytech.</p>
This work coincided with Timo Kösters highlighting an issue to security@matrix.org</a> that the room creator always has had complete power over the room and dominates other admins. This works even if the creator had left the room or gave away their admin permissions in the past. This spurred the creation of MSC4289</a> which formally acknowledges the power that creators have over every other member in the room. We’d like to thank Timo for reporting these points to security@matrix.org</a> and we will be adding him to the Security Hall of Fame.</p>
The security review also brought to light another potentially serious vulnerability in the federation protocol. Our on-paper analysis suggested it may be possible to replace the create event in the room. If so, this would have grave consequences as all permissions in the room are derived from the create event.</p>
However, when we tried to reproduce the vulnerability in real implementations we found that they were not vulnerable due to the way those implementations handled rejected events. Nevertheless, the protocol was missing a strong guarantee that there can never be multiple create events for the same room. This was sufficiently worrying as a soundness issue to warrant fixing, and so MSC4291</a> was created to guarantee that each room has exactly one immutable create event.</p>
We took the unusual decision to embargo these MSCs due to risk of exploitation, taking each in turn:</p>

MSC4289</a>: The risk of a room created by a user on a server that is no longer trusted, using their creator powers to disrupt the room</li>
MSC4291</a>: The risk of an unknown vector allowing multiple create events to be accepted into a room, allowing rooms to be taken over.</li>
MSC4297</a>: The risk of manipulation of the federation re-sync mechanism allowing state resets to be intentionally triggered.</li>
</ul>
These MSCs were reviewed under embargo by the SCT and server implementors, and passed final comment period for merge. These MSCs are bundled up into room version 12</a>, expected to be released formally in Matrix 1.16 later this month.</p>
This work fixes the most common set of state resets we’ve seen in the wild, although we’re continuing work on Hydra. We’ll be doing as much of this work as possible in the open to minimise any future embargoes. We’d like to thank all the server implementors (Conduit</a>, Continuwuity</a>, ejabberd</a>, Dendrite</a>, Rocket.chat</a>, Synapse</a>, Synapse Pro</a> and Tuwunel</a>) who took the time to make these changes at such short notice.</p>
We’d also like to thank the client/bot/bridge implementors for accommodating the client-side breaking changes introduced in room version 12, particularly around the new power level semantics and room ID format change.</p>
Finally, we’d like to thank the community at large, particularly those who have been disrupted and have had to upgrade rooms in response to this work. Thanks all for your patience, and we look forward to a talk all about this at the Matrix Conference</a> in October!</p>


Security Release
2025-08-11T00:00:00+00:00
Hi all,</p>
Last month we issued a Pre-disclosure: Upcoming coordinated security fix for all Matrix server implementations</a>, 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.</p>
</span>
🔗</a>What is changing?</h2>
Room version 12 includes some changes to the semantics for room creators. Room creators are now privileged over other users in the room as of MSC4289</a>. There is also a new additional_creators</code> field in the m.room.create</code> event for a room.</p>
The default power level in room version 12 for sending m.room.tombstone</code> events to upgrade rooms is now 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.</p>
Room IDs are now hashes of the m.room.create</code> event via MSC4291</a>. This changes the format of the room ID that you are used to seeing, and your Matrix client will need to be updated to handle this new format.</p>
🔗</a>What do I need to do?</h2>
🔗</a>As a Matrix user</h3>
Upgrade your client to the latest version, making sure that it supports room version 12. Check your client’s upgrade notes or documentation for information on room version 12 support.</p>
🔗</a>As a Matrix server administrator</h3>
Upgrade your server software to the latest version, making sure that it supports room version 12. The following implementations are releasing fixes shortly as part of this coordinated update:</p>

Conduit</a></li>
Continuwuity</a></li>
ejabberd</a></li>
Dendrite</a></li>
Rocket.chat</a></li>
Synapse</a></li>
Synapse Pro</a></li>
Tuwunel</a></li>
</ul>
For questions around these implementations, please visit their respective support rooms.</p>
Note: Whether or not you need to apply the security updates depends on your homeserver configuration:</p>

Single instance, unfederated homeserver</em>

You are running a single instance of a Matrix homeserver, and federation is disabled. There is nothing you need to do urgently.</li>
Homeservers operating in a restricted federation</em>

Your server(s) are running as part of a restricted federation - i.e. you have mechanisms in place (homeserver configuration, network restrictions etc) that limit which other homeservers your homeservers can talk to.

If you fully trust</em> all of the homeservers in this restricted federation then there is nothing you need to do urgently.</li>
If you do not fully trust</em> all of the homeservers in this restricted federation (e.g. if they are run by partners outside of your direct span of control), you should update your server as soon as possible.</li>
</ul>
</li>
Homeservers participating in open, unrestricted federation</em>

If your server is participating in an open federation, you should update your server as soon as possible.</li>
</ul>
🔗</a>As a room owner or community</h3>
If your rooms or spaces federate with untrusted servers, you should plan</strong> to upgrade your rooms to room version 12. The urgency of this upgrade may depend on your community’s readiness for the changes. At the Foundation, we are aiming to upgrade our rooms in September 2025. There needs to be enough time to allow clients and servers participating in your room to support version 12 before upgrading your room</em>.</p>
The new version includes some changes to room creator semantics, which means that choosing which user performs the upgrade needs some careful thought. Using a long-lived, trusted account, such as a moderation bot account, is advised. For more detailed advice, two of the Foundation Governing Board working groups — the Trust & Safety Research & Development Working Group, and the Website & Content Working Group — have collaborated on a guide for upgrading rooms and spaces</a> to version 12. That guide will help you to plan your upgrades and to make them happen.</p>


Pre-disclosure: Upcoming coordinated security fix for all Matrix server implementations
2025-07-16T00:00:00+00:00
Hi all,</p>
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).</p>
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</strong></del> Monday Aug 11th 2025 at 17:00 UTC</strong>.  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.</p>
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</strong>) 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</del> Thursday Aug 14th 2025 at 17:00 UTC.</p>
UPDATE: Jul 18th 16:45 UTC</strong>: 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</strong>, to give everyone more time to test and prepare.  We've also opened up registration on the beta.matrix.org</code> 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</code> events.</p>
CLARIFICATION: Jul 16 17:30 UTC</strong>: 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.</p>
Important information for client developers:</strong></p>


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

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</strong> listed in the users block of the m.room.power_levels</code> event, and are instead defined as the sender</code> field of the m.room.create</code> event, or entries in a new optional additional_creators</code> array field in the content</code> of the create event. Full details will be released in the MSCs when embargo lifts.</p>
</li>

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

UPDATE: Jul 18th</strong>: We should have mentioned that the default power level in room v12 for sending m.room.tombstone</code> 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.</p>
</li>
</ul>
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.</p>
We’ll follow up with more details on Aug 11th (assuming the disclosure timeline doesn’t slip further).</p>
Thanks all for your time, patience and understanding while we ship this protocol upgrade (the first coordinated upgrade since Matrix 1.0</a> back in 2019!)</p>
Matthew</p>


Security disclosure for matrix-js-sdk (CVE-2024-47080) and matrix-react-sdk (CVE-2024-47824)
2024-10-15T11:39:35+00:00
Hi all,</p>
We are disclosing two high-severity vulnerabilities in matrix-js-sdk and matrix-react-sdk related to MSC3061</a>, which specifies sharing room keys with newly invited users for message history access.</p>
🔗</a>Affected versions</h3>

matrix-js-sdk</strong> ≥ 9.11.0, < 34.8.0 (CVE-2024-47080</a> / GHSA-4jf8-g8wp-cx7c</a>). Fixed in 34.8.0.</li>
matrix-react-sdk</strong> ≥ 3.18.0, < 3.102.0 (CVE-2024-47824</a> / GHSA-qcvh-p9jq-wp8v</a>). Fixed in 3.102.0.</li>
</ul>
🔗</a>Vulnerability details</h3>
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</em> keys to the invited user as for sending new</em> 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.</p>
🔗</a>Root cause and remediation</h3>
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.</p>
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</code> rather than initCrypto</code>) are not</em> vulnerable, even if on a nominally vulnerable version.</p>
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.</p>
🔗</a>Proposed specification changes</h3>
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.</p>
🔗</a>Note on project ownership</h3>
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</a>. 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.</p>


Disclosure: Bridges security issues
2023-08-04T10:30:00+00:00
Hi folks. As previously mentioned on Monday</a>, 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.</p>
Today we are disclosing the 3 vulnerabilities.</p>
🔗</a>matrix-appservice-bridge doesn't verify the sub parameter of an openId token exchange (CVE-2023-38691)</h2>
GHSA-vc7j-h8xg-fv5x</a> / CVE-2023-38691</a></p>
The POST /v1/exchange_openid</code> endpoint did not check that the servername part of the sub</code> parameter (containing the user's claimed</em> 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</code> parameter according to the user they want to act as and use the resulting token to perform provisioning requests.</p>
This is now patched so that the server part of the sub / user ID is checked against the server used to make the request.</p>
Discovered and reported by a community member.</p>
🔗</a>IRC command injection via admin commands containing newlines (CVE-2023-38690)</h2>
GHSA-3pmj-jqqp-2mj3</a> / CVE-2023-38690</a></p>
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.</p>
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.</p>
Discovered and reported by Val Lorentz</a>.</p>
🔗</a>Events can be crafted to leak parts of targeted messages from other bridged rooms (CVE-2023-38700)</h2>
GHSA-c7hh-3v6c-fj4q</a> / CVE-2023-38700</a></p>
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.</p>
Discovered and reported by Val Lorentz</a>.</p>
If you have further questions, please reach out on security@matrix.org</a></p>


Bridges Security Update
2023-07-31T11:40:00+00:00
Today we are announcing security updates for several of our bridges.</p>

matrix-appservice-irc 1.0.1</a> affected by GHSA-vc7j-h8xg-fv5x CVE-2023-38691</a>, GHSA-3pmj-jqqp-2mj3 / CVE-2023-38690</a>, and GHSA-c7hh-3v6c-fj4q</li>
matrix-hookshot 4.4.1</a> affected by GHSA-vc7j-h8xg-fv5x / CVE-2023-38691</a></li>
matrix-appservice-slack 2.1.2</a> affected by GHSA-vc7j-h8xg-fv5x / CVE-2023-38691</a></li>
</ul>
In addition we have released matrix-appservice-bridge 9.0.1</a> (and backported to 8.1.2</a>) which patches GHSA-vc7j-h8xg-fv5x.</p>
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).</p>
</span>

IRC bridge config</a>

Set provisioning.enabled</code> to false.</li>
</ul>
</li>
Slack bridge config</a>

Set provisioning.enabled</code> to false.</li>
</ul>
</li>
Hookshot config</a>

Remove the widgets</code> resource (NOT provisioning)</li>
</ul>
</li>
</ul>
The IRC bridge is also affected by two additional vulnerabilities. In this case, we would recommend upgrading immediately</strong> rather than working around the problems.</p>
Disclosures for these vulnerabilities, as well as CVE numbers will be out in three days (Thursday 3rd).</p>
We advise to upgrade as soon as possible.</strong></p>
If you have further questions, please reach out on security@matrix.org</a></p>


Postponing the Libera.Chat deportalling
2023-07-28T14:00:00+00:00
We have recently announced that we will be honouring Libera Chat’s request</a> 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</a> so the bridge keeps working for them.</p>
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.</p>
</span>
Additionally, as part of the project we have been made aware of several new bridge security issues. These issues must be patched ahead of the plumbing stability work thereby increasing the overall scope of the project. The limited resources of the Matrix.org</a> Foundation didn’t allow us to meet the deadline in time.</p>
Rather than plough ahead with the original timeline and risking splitting communities, we have asked Libera Chat for an extension for turning off portal rooms to ensure successful migrations in order to make sure the bridge is ready to handle the traffic in plumbed rooms and to leave people enough time to migrate their rooms after the stabilisation work. We have asked the Libera Chat staff to allow us to postpone the deportalling to Friday 11 August, which they accepted. We’re grateful to the Libera Chat team for accommodating us.</p>
We will turn off the new portal creation on Monday 31 July, but will leave the existing portals active. On Friday 11 August we will make all the portal rooms read-only, and will send a message in each portalled room to list all the public rooms plumbed to the same channel on IRC.</p>
🔗</a>Security release information</h2>
On Monday 31st, we will release new security updates for several bridges and the matrix-appservice-bridge library, including the IRC bridge. These will be:</p>

matrix-appservice-bridge 9.0.1</li>
matrix-appservice-irc 1.0.1</li>
matrix-appservice-slack 2.1.2</li>
matrix-hookshot 4.4.1</li>
</ul>
We, and the community, have found several vulnerabilities classified as High severity and strongly recommend upgrading as soon as possible after the release.</p>
A full disclosure of the vulnerabilities will be out 3 days after the release, to allow people time to upgrade.</p>


Disclosing Synapse security advisories
2023-05-24T13:44:36+00:00
Today we are retroactively publishing advisories for security bugs in Synapse</a>. From oldest to most recent, they are:</p>

GHSA-p9qp-c452-f9r7</a> (CVE-2022-39374</a>), fixed in Synapse 1.68.0 and affecting all prior versions since Synapse 1.62.0;</li>
GHSA-45cj-f97f-ggwv</a> (CVE-2022-39335</a>), fixed in Synapse 1.69.0 and affecting all prior versions; and finally</li>
GHSA-f3wc-3vxv-xmvr</a> (CVE-2023-32323</a>), fixed in Synapse 1.74.0 and affecting all prior versions.</li>
</ul>
We strongly advise Synapse operators who are still on earlier Synapse versions to upgrade to the latest version (v1.84.0</a>) or at the very least v1.74.0 (released Dec 2022</a>), to prevent attacks based on these vulnerabilities. Please see the advisories for the full details, including a description of</p>

the vulnerability and potential attacks,</li>
exactly which deployments are vulnerable, and</li>
workarounds and mitigations.</li>
</ul>
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</a> to the Matrix.org foundation.</p>
If you have any questions or comments about this announcement or any of the advisories, e-mail us at security@matrix.org</a>.</p>


Security releases: matrix-js-sdk 24.0.0 and matrix-react-sdk 3.69.0
2023-03-28T00:00:00+00:00
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</a>
/ GHSA-mwq8-fjpf-c2gr</a>
for matrix-js-sdk and
CVE-2023-28103</a>
/ GHSA-6g43-88cp-w5gv</a>
for matrix-react-sdk).</p>
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.</p>
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.</p>
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.</p>
We found these issues during a codebase audit that we had previously
announced</a>
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</a>
/ GHSA-rfv9-x7hh-xc32</a>
and
CVE-2022-36060</a>
/ GHSA-2x9c-qwgf-94xr</a>,
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.</p>


Upgrade now to address E2EE vulnerabilities in matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk2
2022-09-28T17:41:33+00:00
TL;DR:</strong></p>

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.</li>
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.</li>
Please upgrade immediately in order to be protected against these
vulnerabilities.</strong></li>
Clients with other encryption implementations (including Hydrogen, ElementX,
Nheko, FluffyChat, Syphon, Timmy, Gomuks and Pantalaimon) are not affected;
this is not a protocol bug</strong>.</li>
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.</li>
This resolves the pre-disclosure</a> issued on September 23rd.</li>
</ul>
</span>
Hi all,</p>
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.</p>
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.</strong></p>
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.</p>
Please note that the critical severity issues are implementation issues in
matrix-js-sdk and derivatives, and are not</strong> 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.</p>
The two critical severity issues lead to three attack scenarios, all of which
are prevented by today's releases:</p>


"Key/Device Identifier Confusion in SAS Verification</em>" – 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.</p>
</li>

"Trusted Impersonation</em>" – 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).</p>
</li>

"Malicious key backup</em>" – 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".</p>
</li>
</ul>
Three lower priority issues were also identified by the researchers:</p>


"Semi-trusted Impersonation</em>" – 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).</p>
</li>

"Homeserver Control of Room Membership</em>" – 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.</p>
</li>

"IND-CCA break</em>" – 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.</p>
</li>
</ul>
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</a>.</p>
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.</p>
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</strong> 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.</p>
We started the process of auditing matrix-rust-sdk with the Least Authority
vodozemac audit in May</a>, 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</a> has not
progressed), but we will be shifting to the new audited codebase as rapidly as
we possibly can.</p>
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</a> (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</a> and Traffic
Light</a> to stress-test encryption
and improve reliability.</p>
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.</p>
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.</p>
Matthew, Denis and the Matrix cryptography & security teams.</p>


Pre-disclosure: upcoming critical security release of Matrix SDKs and clients
2022-09-23T14:53:12+00:00
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</strong> security issues, on Wed, Sept 28th</strong>. 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.</p>
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.</p>
If you maintain or package a (potentially) affected E2EE-capable Matrix client and need to coordinate on the release, please contact security@matrix.org</a>.</p>
We advise to upgrade as soon as possible after the patched versions are released.</strong></p>
Thank you for your patience while we work to resolve this issue.</p>


Security release of matrix-appservice-irc 0.35.0 (High severity)
2022-09-13T16:56:43+00:00
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:</p>

IRC mode operator confusion (Low, GHSA-cq7q-5c67-w39w</a>)</li>
Parsing issue leading to room takeovers (High, GHSA-xvqg-mv25-rwvw</a>)</li>
Undisclosed issue (Moderate, GHSA-r3p6-cg2c-c4qw</a>)</li>
</ul>
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.</p>
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</a>.</p>
The bridges running on the Libera Chat, OFTC and other networks bridged by the
Matrix.org Foundation have been patched.</p>
Please upgrade your IRC bridge as soon as possible.</strong></p>
The above vulnerabilities were reported by Val
Lorentz</a>. Thank you!</p>


Security releases: matrix-js-sdk 19.4.0 and matrix-react-sdk 3.53.0
2022-08-31T18:13:45+00:00
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</a>
for the matrix-js-sdk and
CVE-2022-36060</a>
for the matrix-react-sdk).</p>
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.</p>
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.</p>
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.</p>
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.</p>
We thank Val Lorentz</a> who discovered and
reported the vulnerability over the weekend.</p>


Security release: Synapse 1.61.1
2022-06-28T16:19:45+00:00
Hey everyone!</p>
Today we're exceptionally releasing Synapse
1.61.1</a>, which comes
as a security release. Server administrators are encouraged to update as soon as
possible.</strong></p>
This release fixes a vulnerability with Synapse's URL preview feature. URL
previews of some web pages can lead to unbounded recursion, causing the request
to either fail, or in some cases crash the running Synapse process.</p>
Homeservers with the url_preview_enabled</code> configuration option set to false</code>
(the default value) are unaffected. Instances with the enable_media_repo</code>
configuration option set to false</code> are also unaffected, as this also disables
the URL preview functionality.</p>
Server administrators who are unable to update Synapse should disable URL
previews by setting url_preview_enabled: false</code> in their configuration file.
They can also delegate URL preview to a separate, dedicated worker to ensure the
process crashing does not impact other functionality of Synapse.</p>
Please see this security
advisory</a>
for more information.</p>