CVE-2026-48929: Rocket.Chat Auth Bypass Vulnerability

CVE-2026-48929 Overview

CVE-2026-48929 is an authentication bypass vulnerability in Rocket.Chat that allows unauthenticated attackers to permanently delete uploaded files. The deleteFileMessage Meteor method removes files by ID without enforcing an authentication check. An attacker connecting through an unauthenticated Distributed Data Protocol (DDP) WebSocket can invoke the method and trigger file deletion against any known file identifier. File IDs are recoverable from public channel message payloads and download URLs, making targeting straightforward. The flaw maps to [CWE-287] Improper Authentication and affects integrity of stored uploads across multiple Rocket.Chat release branches.

Critical Impact
Any remote attacker can permanently destroy uploaded files in vulnerable Rocket.Chat instances without credentials, causing irreversible data loss.

Affected Products

Rocket.Chat versions earlier than 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, and 8.0.7
Rocket.Chat versions earlier than 7.13.9
Rocket.Chat versions earlier than 7.10.13

Discovery Timeline

2026-06-17 - CVE-2026-48929 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-48929

Vulnerability Analysis

The vulnerability resides in the deleteFileMessage Meteor method exposed by Rocket.Chat. The method receives a fileID parameter and is intended to permit message authors or privileged roles to remove uploaded attachments. The implementation does not validate that the caller is authenticated before performing the deletion. As a result, the method behaves as an unauthenticated administrative primitive over the DDP WebSocket transport.

Destruction is unconditional. Once the method reaches FileUpload.getStore('Uploads').deleteById(fileID), the file is removed from both the configured storage backend and the database. There is no soft-delete, recycle bin, or recovery path. Attackers only need a list of file IDs, which are easily harvested from public channel message payloads, image previews, and download URLs of the form used by Rocket.Chat to serve uploads.

Root Cause

The authorization gate in deleteFileMessage relies on Meteor.userId() to identify the caller. On an unauthenticated DDP connection, Meteor.userId() returns null. The conditional that should reject anonymous callers is structured such that a null user identifier bypasses the check rather than rejecting the call. Execution falls through to the storage layer and deletes the file referenced by the supplied identifier.

Attack Vector

An attacker opens a DDP WebSocket to the Rocket.Chat server without logging in. The attacker enumerates file identifiers from public channels, embedded message content, or scraped download URLs. The attacker then invokes the deleteFileMessage method over DDP, passing each fileID. The server removes each file from storage and database records. See the HackerOne Security Report and the upstream Rocket.Chat Pull Request #40889 for the patched method and disclosure details.

Detection Methods for CVE-2026-48929

Indicators of Compromise

DDP WebSocket connections that invoke deleteFileMessage without a preceding login method call on the same session.
Unexpected gaps in the rocketchat_uploads collection or storage backend, with corresponding 404 responses on previously valid file download URLs.
Spikes in DDP method traffic from a single source IP enumerating sequential or harvested file IDs.

Detection Strategies

Inspect Rocket.Chat application and proxy logs for DDP method frames containing deleteFileMessage and correlate against authenticated session identifiers.
Alert on file deletions where the executing user context is null or empty in audit records.
Compare snapshots of the uploads collection against object storage inventories to detect unauthorized removals.

Monitoring Recommendations

Forward Rocket.Chat audit logs and reverse proxy WebSocket access logs to a centralized log platform for retention and correlation.
Monitor outbound 404 rates on /file-upload/ and /ufs/ URL paths as a proxy signal for mass deletion activity.
Track baseline rates of deleteFileMessage invocations and alert on deviations above normal operator activity.

How to Mitigate CVE-2026-48929

Immediate Actions Required

Upgrade Rocket.Chat to a fixed release on your current branch: 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, 7.13.9, or 7.10.13.
Restrict network exposure of the Rocket.Chat DDP and HTTP endpoints to trusted networks or behind an authenticating reverse proxy until patched.
Back up the uploads storage backend and database collections so destroyed files can be restored if exploitation is detected.

Patch Information

Rocket.Chat addressed the issue by enforcing an authentication and authorization check inside the deleteFileMessage method, rejecting calls where Meteor.userId() is null and validating that the caller owns the message or holds a privileged role. The fix is documented in Rocket.Chat Pull Request #40889. Operators running self-hosted deployments should upgrade to the patched point release on their current minor branch.

Workarounds

Place Rocket.Chat behind a reverse proxy that requires an authenticated session cookie before allowing WebSocket upgrades to /websocket.
Apply rate limiting and WAF rules to block DDP frames containing the deleteFileMessage method name from unauthenticated sessions.
Enable storage-side object versioning or immutability (for example, S3 Object Lock) so deletions are recoverable until the patch is applied.

bash

# Example: verify the running Rocket.Chat version against the fixed releases
curl -s https://chat.example.com/api/info | jq '.version'
# Upgrade via official channels, for example with the snap package:
sudo snap refresh rocketchat-server --channel=8.5/stable