EUVD-2026-39092Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N
Any authenticated user can trigger it over the network with low complexity (PR:L, AV:N, AC:L); rewriting storage metadata to access other data crosses a security boundary (S:C) yielding high confidentiality, low integrity, no availability impact.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
2DescriptionCVE.org
Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11, Rocket.Chat's sendFileMessage DDP method passes the entire attacker-supplied file object into Uploads.updateFileComplete, which merges it directly into a MongoDB $set update via Object.assign. There is no allow-list of writable fields. An attacker can therefore rewrite any column on their own upload record, notably store and the store-specific path fields. This vulnerability is fixed in 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11.
AnalysisAI
Insecure object property modification (mass assignment) in Rocket.Chat's file-upload completion flow allows a low-privileged authenticated user to overwrite arbitrary fields on their own upload record, including the storage backend (store) and store-specific path fields. The flaw stems from sendFileMessage passing the entire attacker-controlled file object into Uploads.updateFileComplete, which Object.assigns it into a MongoDB $set with no writable-field allow-list, enabling an attacker to repoint their upload metadata at arbitrary storage locations and disclose sensitive data. No public exploit identified at time of analysis, and it is not listed in CISA KEV; the issue affects all releases prior to the fixed 8.5.0/8.4.1/8.3.3/8.2.3/8.1.4/8.0.5/7.13.7/7.10.11 builds.
Technical ContextAI
Rocket.Chat is a Node.js/Meteor-based open-source team-communication platform that uses MongoDB for persistence and a pluggable upload-store abstraction (GridFS, filesystem, S3, etc.). File uploads are completed via the DDP (Distributed Data Protocol) method sendFileMessage, which forwards the client-supplied file object to Uploads.updateFileComplete. That function merges the object directly into a Mongo $set document using Object.assign without validating which keys are writable - the textbook CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes, i.e., mass assignment). Because the 'store' field and the corresponding store-specific 'path' fields are writable, an attacker can rewrite how the platform locates and serves the file content, decoupling the served bytes from what the uploader was authorized to provide.
RemediationAI
Upgrade to a patched release on your branch: Rocket.Chat 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, or 7.10.11 (pick the fixed version matching your current major/minor line) per the vendor advisory at https://github.com/RocketChat/Rocket.Chat/security/advisories/GHSA-fhc2-x8cp-c5ch. Because exploitation requires an authenticated account, an effective interim compensating control is to disable open/self-registration (Admin > Settings > Accounts > Registration > set 'Registration Form' to Disabled or Secret URL) to shrink the attacker population, accepting the trade-off that legitimate self-onboarding stops. Additionally restrict or monitor the file-upload feature (Admin > Settings > File Upload) and audit upload records for unexpected changes to 'store' or path fields; note that disabling file uploads breaks a core collaboration feature, so it is a last resort. No vendor-released patch beyond the listed fixed versions is needed - apply the upgrade as the durable fix rather than relying on workarounds.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today