Gravity of the Situation: Security Analysis on Rocket.Chat E2EE

What is Rocket.Chat?

Rocket.Chat is a widely deployed group chat platform used across enterprises, public-sector organizations, educational institutions, and self-hosted environments. It serves over 15 million users in 150 countries and supports both SaaS and on-premises deployments.

A key feature of this platform is End-to-End Encryption (E2EE) for group chats. E2EE is intended to protect confidentiality and integrity even if the server is untrusted, but real-world security depends on both protocol design and correct implementation. Our research conducts the first in-depth security & cryptographic analysis of Rocket.Chat E2EE protocol and implementation.

Through this analysis, we discovered practical attacks, including key recovery that affects message confidentiality and encrypted message forgery. These attacks can break the core confidentiality and integrity guarantees expected from E2EE. We reported our findings to the Rocket.Chat Technology security team and worked collaboratively with them. As a result, critical issues affecting confidentiality and integrity identified in our report have been addressed, and patches have been released. Rocket.Chat also acknowledged the remaining issues we reported. They stated that remaining unpatched issues are currently being treated as risk accepted and will be reviewed in the future.

Note:

For readability, this page and our paper use the present tense. However, critical vulnerabilities reported in this work have already been addressed, and vendor patches are available (see Disclosure).

Results — Our Security Findings

Rocket.Chat E2EE consists of three protocols: (1) RSA-based key exchange and AES-CBC-based message encryption, (2) password-based encryption (the E2EE password) for key backup, and (3) the E2EE password update/reset feature. We analyze these protocols in an end-to-end manner.

We conduct the first comprehensive security analysis of Rocket.Chat’s E2EE by combining formal verification (ProVerif) with extensive manual analysis (specification + source code + operational testing).

• 6 vulnerabilities, 5 practical attacks, and several potential issues (hardening recommendations)
• Attacks impacting both confidentiality and integrity
• Relevant adversaries include a malicious server and, in some deployments, outsider / network attackers

Our key findings include:

1. Practical RSA Private Key Recovery (Offline Attack)
   

   A malicious server can recover a user’s RSA private key in practical time (days to months), enabling decryption of all past and future E2EE messages.

   • Root cause: The private-key backup mechanism enables an offline brute-force attack because the initial E2EE password space is too small, and the real implementations further reduce security through biased generation.
   • The Flaw (Mobile App): We identified a severe bug in the mobile application (v4.48.0). The password generation algorithm is intended to draw from 62 alphanumeric symbols, but it applies a toLowerCase function to the output.
     • Bias & Practical Search: The effective password space is already small (roughly 2^46.53). Moreover, the generator is non-uniform due to the use of toLowerCase. Compared to a standard uniform random choice from the same 36-character pool (lowercase letters + digits), lowercase letters appear with roughly twice the probability. In practice, an attacker can exploit this bias by prioritizing candidates that contain letters, substantially improving the success rate (e.g., by over 32% compared to uniform search under the same time budget).
   • The Flaw (Web App): The web client also suffers from low entropy (2^53.36), generating passwords from a small permutation of words.

2. Group Key Compromise (MITM Attack)
   

   We identified a Lack of Authenticity for Public Keys. Since the protocol does not verify RSA public keys, a malicious server or network attacker can perform a Man-in-the-Middle (MITM) attack.

   • Impact: An attacker can replace or inject keys during the setup phase, allowing them to eavesdrop on all encrypted communications or impersonate legitimate users without detection.

3. Practical Encrypted Message Forgery (Lack of Integrity)
   

   Due to the use of AES-CBC without a MAC and the fact that the ciphertext embeds a copy of message metadata, an attacker can obtain a known-plaintext block corresponding to part of the CBC-encrypted message. We show that observing only a single ciphertext is sufficient to mount a practical ciphertext-malleability attack, enabling the attacker to forge valid encrypted message blocks containing arbitrary text.

4. E2EE password update/reset feature does not revoke compromised keys.
   

   The E2EE password update/reset feature does not update (rotate) the room group key. This means that once the group key is compromised, the compromise can persist: an adversary who obtains the group key via MITM, or who recovers the victim’s RSA private key and derives group keys, can keep decrypting and forging messages even after the victim updates or resets the E2EE password.

Other findings.

Our paper provides additional in-depth analysis beyond the core attacks. It includes immediately applicable fixes (implementation-level patches), further recommended improvements (e.g., a design using the Passkey PRF), and a discussion of how to introduce key authenticity in on-premises deployments.

We also report several potential issues and supporting analyses, including the KeyID issue (ID collisions and potential key leakage), replay attacks, denial-of-service attacks, and downgrade attacks. In addition, we identify gaps between the Rocket.Chat E2EE documentation and the deployed implementation (see the Appendix), and we analyze affected instances using Shodan. Issues impacting confidentiality have already been addressed (see the Appendix and Disclosure).

Disclosure

We follow responsible disclosure and coordinate with the Rocket.Chat security team. We first contacted the vendor on May 30, 2024 and received the first response on June 26, 2024.
We informed the Rocket.Chat Security Team of our publication and presentation schedule, and they agreed to it.

• We reported 6 vulnerabilities and 5 attacks, plus 3 potential issues.
• Rocket.Chat acknowledged all reported issues.
• Still open: public-key authenticity.

Patch Status:

Note: This table is horizontally scrollable on smartphones.

Vulnerability	Status	Fixed Version / Release Date
RSA Private Key Recovery (Offline Brute-force Attack)	Fixed	Patched in Rocket.Chat Mobile v4.51.0 (Oct 2024) CVE-2024-42027 Strong bias in the password generator has been fixed. Improved Password entropy. PBKDF2 iterations increased from 1,000 to 100,000.
Group Key Update Issues (The E2EE password update/reset feature did not update the group key)	Fixed	Patched in version 7.0 (Nov 2024) Implemented group key rotation features in v7.0.
Message Integrity (Forgery Attacks)	Fixed	Patched in version v7.13.0 (Dec 2025) Migration from AES-CBC to AES-GCM has already been addressed in v7.13.0.
KeyID Issues (Key ID collision)	Fixed	Patched in version 7.0 (Nov 2024) Improved KeyID derivation.
Public Key Authenticity (Man-in-the-Middle Attack by Malicious Server)	Unfixed	Currently, clients do not verify the peer user's public key in E2EE. This can be exploited by a malicious server administrator or an attacker who has compromised the server. If TLS is properly deployed and strictly enforced, external network attackers cannot practically exploit this issue. See FAQ (Q4) for details.

Statement from the Rocket.Chat Security Team (Nov 23, 2025):
“Other issues mentioned in the report are currently being treated as risk accepted and will be reviewed in the future. For now, we're considering this report to be solved and we're closing it.”

Paper & Talk

Hayato KIMURA, Ryoma ITO, Kazuhiko MINEMATSU and Takanori ISOBE,
“Gravity of the Situation: Security Analysis on Rocket.Chat E2EE”
Accepted at ACSAC 2025 (Oct 2025) and presented on Dec 10, 2025.

Read PDF

BibTeX Citation

@inproceedings{acsac/KimuraIMI25,
  author       = {Hayato Kimura and
                  Ryoma Ito and
                  Kazuhiko Minematsu and
                  Takanori Isobe},
  title        = {Gravity of the Situation: Security Analysis on Rocket.Chat E2EE},
  booktitle    = {Annual Computer Security Applications Conference, {ACSAC} 2025, Honolulu,
                  HI, USA, December 8-12, 2025},
  pages        = {15--30},
  publisher    = {{IEEE}},
  year         = {2025},
  url          = {https://doi.org/10.1109/ACSAC67867.2025.00018},
  doi          = {10.1109/ACSAC67867.2025.00018},
}

Proof of Concept

Proof-of-concept code and reproducible instructions are available on GitHub.

We implement working Proof-of-Concept (PoC) exploits to validate exploitability and support vendor verification.

• Web-client PoCs: Rocket.Chat web application v6.8.0
• Offline key recovery PoC: Rocket.Chat mobile application v4.48.0
• HTTP Proxy-based active attacker experiments (e.g., BurpSuite / mitmproxy / ZAP / PacketProxy)

Go to GitHub

FAQ

Q1. Which versions are affected?
Our findings affect following Rocket.Chat E2EE version. We strongly recommend upgrading to patched releases.

• Rocket.Chat Mobile version prior to 4.51 (for the offline key-recovery attack).
• Rocket.Chat Server version prior to 7.0 (for the group-key-rotation and KeyID issues).
• Rocket.Chat Server version prior to 7.13.0 (for the message-integrity attack).

Important: applying the patch requires updating both the server and the clients to fixed versions.

Q2. I’m a user—what can I do right now?

• Mobile: update Rocket.Chat from your app store (App Store / Google Play) to the latest version.
• Desktop: download and install the latest Rocket.Chat Desktop app from rocket.chat/download-apps.
• Browser (web): the web client is delivered by your workspace server, so you cannot patch it locally. Ask your administrator to upgrade the server (and confirm your workspace is running the patched version).

Q3. I’m a workspace admin—what should I do?
Consider deploying Rocket.Chat server v7.13.0 or later (preferably the latest available release), and ask all users of your instance to install the latest Rocket.Chat apps as well. If your server does not enforce TLS, enable TLS 1.3 (or TLS 1.2) to protect against network adversary. See: Rocket Chat SSL Support for Dev - Rocket.Chat Docs .

Q4. Who can exploit the Public Key Authenticity issue (MITM by a malicious server)?
This issue is exploitable by a malicious server administrator or an attacker who has compromised the Rocket.Chat server, because the server can replace or inject users’ public keys during E2EE setup or key distribution.

If TLS is properly deployed and strictly enforced, an external network attacker cannot practically exploit this issue because they cannot intercept and modify the traffic in transit.

Deploying a fix requires additional feature development. For example:

• Introduce out-of-band key authentication. This is relatively easy for developers to implement, but it requires users to actively verify keys.
• Alternatively, adopt a modern key-authentication approach such as Key Transparency. This may introduce operational challenges in on-premises deployments (see our paper).

Team

---

Hayato KIMURA (NICT & The University of Osaka)

Ryoma ITO (NICT)

Kazuhiko MINEMATSU (NEC)

Takanori ISOBE (The University of Osaka)