Topic starter
02/08/2026 11:22 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “Predicting MongoDB ObjectId continuously in Rocket.Chat”.
By the numbers:
- As of June 12th, the issue was fixed in versions 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, 7.13.9, and 7.10.13.
Key questions
Q: What breaks when object-level authorisation is not bound to the exact file or record being fetched?
A: The control fails when the system authorises one context, such as a room or session, but serves a different object from the path or query string.
Q: Why are predictable MongoDB ObjectId values risky in application access controls?
A: Because they are structured, not random, and their timestamp plus counter layout can be inferred once an attacker sees one valid value.
Q: How do security teams test for IDOR effectively?
A: They should create multiple identities, generate separate objects for each one, and replay the same requests across roles, sessions, and workflow stages.
Practitioner guidance
- Verify object-to-context binding Ensure the file or record being returned is the same object that was authorised, not just another item in the same room, account, or session.
- Replace structured IDs with high-entropy identifiers Use UUIDv4 or an equivalent high-entropy scheme for externally visible object references so predictable timestamps and counters cannot be walked.
- Test object-level authorisation separately from session checks Add tests that attempt to reuse a valid visitor token, room token, or user session against a different object ID to confirm the access decision fails.
Bottom line: Predictable object identifiers can make an IDOR far easier to exploit, but the root failure is still missing object-level authorisation.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:40 pm
Object opacity is not authorisation: This incident works because the application treated a predictable identifier as if it were a security control. MongoDB ObjectId may look random, but it was never designed to prove who may fetch a file. The practitioner lesson is that access decisions must be explicit and object-specific, not inferred from identifier difficulty.
A few things that frame the scale:
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should organisations use random-looking object IDs as a security control?
A: No. Random-looking IDs can reduce casual guessing, but they do not replace access checks, ownership validation, or tenant binding. The safe pattern is to assume every externally visible identifier will be tested and to make the authorisation decision independent of identifier secrecy.
👉 Read our full editorial: Predicting MongoDB ObjectId turns Rocket.Chat file access into IDOR