CVE-2026-120425 in Chatify
Summary
by MITRE • 11/02/2026
Chatify before 1.6.4 contains an authorization bypass vulnerability in the Pusher channel authorization endpoint that allows authenticated users to subscribe to other users' private channels by supplying arbitrary channel names. Attackers can request a signature for private-chatify.<victim id> via POST /chat/auth to receive the victim's incoming private messages and attachments in real time.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in Chatify versions prior to 1.6.4 represents a critical authorization bypass within the application's real-time communication infrastructure, specifically targeting the Pusher channel authentication mechanism. This flaw stems from insufficient validation of input parameters during the request handling process for private channels. In secure implementations, when an authenticated user attempts to subscribe to a private or presence channel, the server must verify that the requesting user has explicit permission to access resources associated with that specific channel identifier. However, in this affected version, the endpoint responsible for generating authentication signatures fails to enforce strict ownership checks against the provided channel name. This architectural oversight allows any logged-in user to manipulate the request payload by supplying arbitrary channel names rather than restricting subscriptions to channels explicitly linked to their own account or authorized contacts.
From a technical perspective, the exploitation of this vulnerability relies on the predictable naming convention often used in chat applications, where private channels are typically named using patterns such as private-chatify followed by a unique user identifier. By crafting a POST request to the /chat/auth endpoint and injecting a target victim's ID into the channel name parameter, an attacker can successfully obtain a valid authentication signature for that specific channel. The Pusher service then grants access based on this signature without further verifying if the requester is actually authorized to view messages intended for the identified user. This effectively neutralizes the security boundary designed to keep private conversations confidential between two parties, turning what should be a secure, authenticated interaction into an open information leak accessible to any other registered user of the platform.
The operational impact of this vulnerability is severe, as it directly compromises the confidentiality and integrity of real-time communications. An attacker who exploits this flaw can subscribe to the victim's private channel in real time, thereby receiving all incoming messages, media attachments, and potentially sensitive metadata associated with those conversations. This capability transforms a standard messaging application into an instrument for unauthorized surveillance or data exfiltration. Victims may inadvertently share personal information, corporate secrets, or other confidential data under the assumption that their communications are secure. Furthermore, because the attack requires only valid authentication credentials which are common in many social engineering scenarios such as session hijacking or credential theft, the barrier to entry for an attacker is relatively low compared to vulnerabilities requiring unauthenticated access.
This issue aligns with CWE-284 Improper Access Control and falls under MITRE ATT&CK technique T1530 Data from Cloud Storage Objects if one considers the message stream as a data object, or more accurately T1071 Application Layer Protocol for command and control exfiltration patterns where sensitive data is moved laterally. To mitigate this risk, developers must implement strict server-side validation that ensures the authenticated user's identity matches the owner of the requested channel before issuing any authentication tokens. This involves querying the database to confirm ownership relationships or explicit permissions associated with the specific channel ID provided in the request payload. Additionally, implementing rate limiting and anomaly detection on the authorization endpoint can help identify and block automated attempts to enumerate valid channel IDs by observing patterns of failed or suspicious subscription requests. Upgrading to version 1.6.4 or later is essential as it addresses these logic flaws within the core authentication module.