CVE-2026-72918 in Rocket.Chatinfo

Summary

by MITRE • 08/11/2026

Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 7.10.14, 8.0.8, 8.1.7, 8.2.7, 8.3.7, 8.4.5, 8.5.2, and 8.6.1, the stream-notify-user stream in the WebSocket protocol allows an authenticated user to write arbitrary notification bodies because the sender is not checked, and the client-side UI can create an ephemeral fake message in another user's currently open chat. This issue is fixed in versions 7.10.14, 8.0.8, 8.1.7, 8.2.7, 8.3.7, 8.4.5, 8.5.2, and 8.6.1.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Analysis

by VulDB Data Team • 08/11/2026

The vulnerability in Rocket.Chat represents a critical authorization bypass flaw that enables authenticated users to manipulate notification streams within the WebSocket protocol. This issue specifically affects versions prior to 7.10.14, 8.0.8, 8.1.7, 8.2.7, 8.3.7, 8.4.5, 8.5.2, and 8.6.1 where the stream-notify-user endpoint fails to validate the authenticity of message senders. The technical implementation lacks proper sender authentication mechanisms, allowing malicious actors to craft and transmit arbitrary notification payloads that appear to originate from legitimate users. This vulnerability resides within the core messaging infrastructure that handles real-time communication through WebSocket connections.

The operational impact of this vulnerability extends beyond simple notification manipulation to potentially enable sophisticated social engineering attacks and information disclosure. An authenticated attacker can leverage this weakness to create ephemeral fake messages that appear in another user's active chat interface, effectively bypassing normal message validation controls. This capability allows for the injection of misleading notifications, potential phishing attempts, or the creation of false urgency around non-existent events. The client-side UI renders these fabricated messages without proper verification, creating a trust boundary violation where users cannot distinguish between legitimate and malicious communications. This flaw directly relates to CWE-284 Access Control Issues and represents a significant deviation from secure communication protocols.

Security implications include potential escalation of privileges through message manipulation, disruption of normal communication patterns, and undermining user trust in the platform's integrity. The vulnerability enables attackers to impersonate other users within the notification system, which could facilitate further attacks such as credential harvesting or information gathering. From an adversarial perspective, this issue aligns with ATT&CK technique T1566 Phishing and T1078 Valid Accounts, as it allows for the exploitation of authenticated sessions to craft deceptive notifications that appear legitimate to end users. The attack surface is particularly concerning given that Rocket.Chat serves as a communications platform where trust in message authenticity is paramount.

Mitigation strategies should focus on implementing robust sender verification mechanisms within the WebSocket notification streams, ensuring that all messages passing through stream-notify-user are properly authenticated and validated before rendering. Organizations should immediately upgrade to patched versions 7.10.14, 8.0.8, 8.1.7, 8.2.7, 8.3.7, 8.4.5, 8.5.2, and 8.6.1 to address the authentication bypass. Additional defensive measures include implementing network-level monitoring for anomalous WebSocket traffic patterns and establishing proper access controls that limit notification injection capabilities. Security teams should also consider implementing message integrity checks and digital signatures for critical notifications to ensure authenticity and prevent unauthorized modifications. The fix in these patched versions addresses the root cause by enforcing proper sender validation, thereby closing the security gap that allowed arbitrary notification bodies to be written without verification of the originating user's credentials or permissions.

Responsible

GitHub M

Reservation

08/10/2026

Disclosure

08/11/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Might our Artificial Intelligence support you?

Check our Alexa App!