TL;DR: Rocket.Chat’s unauthenticated file access issue combined an IDOR with predictable MongoDB ObjectId values, allowing an attacker to enumerate and retrieve uploaded files by probing valid IDs, according to Aikido. The real governance problem is assuming a supposedly random identifier can stand in for access control.
NHIMG editorial — based on content published by Aikido covering the Rocket.Chat file access flaw: Predicting MongoDB ObjectId continuously in Rocket.Chat
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when file access is checked against the wrong object?
A: When an application authorizes one context but serves a different object, the access check stops protecting the data path.
Q: Why do predictable object identifiers increase data exposure risk?
A: Predictable identifiers shrink the search space for attackers and make enumeration practical, especially when timestamps or counters can be inferred from a single sample.
Q: How do security teams know whether direct object references are safe enough?
A: They are safe only when every request proves access to the exact object being served, not merely to a nearby context.
Practitioner guidance
- Bind authorization to the requested object Verify that the file or record returned by the handler is the exact object authorised by the access check, not just any object associated with a session, room, or token.
- Stop treating ObjectId as a secret Assume MongoDB ObjectId values are discoverable and partially predictable, then redesign sensitive download paths so identifier knowledge alone never expands access.
- Review every dual-parameter access path Audit endpoints that validate one parameter for access but fetch data with another, especially file download routes, shared links, and helpdesk upload flows.
What's in the full article
Aikido's full blog post covers the exploit details this post intentionally leaves for the source:
- Step-by-step proof of concept showing how the Livechat room and file endpoint were combined to retrieve protected uploads.
- Python exploit logic for probing recent ObjectId ranges and speeding enumeration with asynchronous requests.
- Code-level explanation of the room validation mismatch in Rocket.Chat's file upload handler.
- Discussion of the fix that binds the chosen file to the room check and the versions that were patched.
👉 Read Aikido's analysis of predictable MongoDB ObjectId file access in Rocket.Chat →
Rocket.Chat file access and MongoDB ObjectId predictability: what failed?
Explore further
Predictable object identifiers become breach multipliers when authorization is decoupled from the object. This case is not about MongoDB alone, and it is not just about an IDOR. It shows that once the application treats an ObjectId as a sufficiently hard-to-guess reference, the access model quietly shifts from authorization to obscurity. Practitioners should read that as a warning that object reference design is part of identity control, not just application plumbing.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- Attackers move fast once they have a usable identity primitive, and file-service IDORs follow the same exploitation logic even when the initial primitive is a guessed object reference.
A question worth separating out:
Q: What should teams do first after finding an IDOR in a file service?
A: Contain the exposure by fixing object binding, then review whether any other endpoints reuse the same trust pattern. In parallel, switch externally reachable sensitive objects to non-derivable identifiers and verify that logs can show which object was authorised, requested, and returned.
👉 Read our full editorial: Predicting MongoDB ObjectId turns Rocket.Chat file access into IDOR