Description

matrix-sdk-ui provides GUI-centric utilities on top of matrix-rust-sdk. The message edit validation logic in the `matrix-sdk-ui` crate prior to 0.17.0 is missing a check: when replacing an encrypted event, the replacement event itself is not required to be encrypted. This enables a malicious homeserver administrators (or actors with equivalent power) to impersonate or spoof messages as if they were sent by a victim user. `matrix-sdk-ui` 0.17.0 fixes the message edit validation logic to align with the algorithm for replacement events[^1] described in the Matrix specification. No known workarounds are available.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.9",
  "pubDate": "2026-09-11T21:17:09.517Z",
  "pubdate": "2026-09-11T21:17:09.517Z",
  "executiveSummary": "The matrix-sdk-ui crate prior to version 0.17.0 contains a vulnerability in the message edit validation logic that permits the spoofing of encrypted events.\nThe flaw stems from an insufficient validation mechanism where replacement events are not mandated to maintain the encryption status of the original event being edited.\nThis vulnerability allows a malicious actor with elevated privileges, such as a compromised homeserver administrator or a man-in-the-middle with sufficient control over the server-side infrastructure, to forge message edits.\nBy bypassing the integrity check for encryption state, the attacker can present spoofed content as authentic user-generated edits, effectively undermining the cryptographic guarantees of the Matrix end-to-end encryption (E2EE) protocol.\nThe impact includes potential message forgery and the erosion of user trust in the integrity of communication sessions.\nThe risk is critical for users relying on the integrity of encrypted message threads, as there is no effective configuration-based workaround, requiring a mandatory update to version 0.17.0 to remediate the logic flaw.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the message edit validation logic within matrix-sdk-ui, which failed to strictly enforce the Matrix specification regarding the encryption state of replacement events (m.replace).\nUnder the Matrix specification, a replacement event intended to modify an existing encrypted event must itself be encrypted to maintain the established security boundary and the end-to-end encryption chain.\nIn affected versions (pre-0.17.0), the SDK failed to verify that the replacement event carried the same security properties—specifically the encryption layer—as the event being replaced.\nThe attack flow involves a threat actor with administrative control over a Matrix homeserver. By intercepting or manipulating the event stream, the attacker can inject a malicious replacement event (m.replace) that references a legitimate encrypted event ID sent by a victim.\nBecause the SDK's validation logic does not mandate that this injected m.replace event be encrypted, the client-side library incorrectly processes the unencrypted replacement.\nThe victim's client then incorrectly renders the malicious payload as an edit to the original, valid message. This effectively allows the attacker to rewrite history or spoof messages under the guise of the victim's identity.\nThis exploit bypasses the protections provided by the underlying matrix-rust-sdk encryption handling because the logical failure exists at the GUI-centric utility layer, which performs the final interpretation and display of the event before presenting it to the user.\nNo authentication or client-side privileges are required by the attacker if they can manipulate the homeserver response; the server inherently controls the event stream provided to the client. This vulnerability highlights a failure in the 'trust on first use' and persistent validation model when the client fails to enforce consistency in cryptographic metadata during the edit lifecycle."
}