dbcve.org
CWE-943Weakness · CWE-943

CVE-2026-45689

CRITICAL · 9.1 CVSS v3.1 Published 2026-06-24
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
100/100
Remediation priority · Urgent
Remotely reachable No privileges Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
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, an unauthenticated network attacker obtains a valid Rocket.Chat OAuth access token for an arbitrary user by sending a single HTTP POST with MongoDB query operators to /oauth/token. The Rocket.Chat OAuth2 server does not validate that grant parameters are strings before forwarding them to findOne({...}) against the oauth_apps and oauth_access_tokens collections, so an attacker substitutes {"$ne": null} for client_id, client_secret, and refresh_token and receives a freshly minted {access_token, refresh_token} pair bound to whichever user's refresh token Mongo returned first. The resulting access token is a first-class bearer credential against the full /api/v1/* surface as that user. By iterating with $nin / $regex operators the attacker walks the entire oauth_access_tokens collection, collecting one fresh access token per user per request. If any matched token belongs to an admin, the stolen bearer gives full admin API access (including Apps-Engine app installation, i.e. server-side code execution). No account, credentials, userId, or prior interaction with the instance are required. 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.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

Rocket.Chat's OAuth2 server does not validate that grant parameters are strings before using them in MongoDB queries against oauth_apps and oauth_access_tokens collections. An unauthenticated attacker can send MongoDB query operators (e.g., {"$ne": null}) as client_id, client_secret, or refresh_token to obtain valid access tokens for arbitrary users, including admins. By iterating with $nin/$regex operators, the attacker can collect fresh tokens for all users, enabling full API access and potential server-side code execution via Apps-Engine.

MitigationUpgrade Rocket.Chat to version 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. Additionally, rotate all existing OAuth access tokens and refresh tokens since the server may have been compromised, and review audit logs for suspicious /oauth/token requests with non-string parameter patterns.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify Rocket.Chat server version
    Run the command to display the installed Rocket.Chat version (typically via the admin UI, API endpoint, or package manager)
    Affected if The installed version is 7.x before 7.10.11, or 8.x before 8.0.5 (specifically any version lower than 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, or 8.0.5)
  2. Verify OAuth2 is enabled
    Check Rocket.Chat administration settings for OAuth2/OAuth apps configuration under the OAuth section in admin panel or via API
    Affected if OAuth2 is enabled and there are oauth_apps configured in the MongoDB oauth_apps collection
  3. Inspect oauth_access_tokens collection
    Query the MongoDB oauth_access_tokens collection for documents where client_id, client_secret, or refresh_token fields contain MongoDB query operator patterns such as $ne, $nin, $regex, or objects starting with $
    Affected if Any documents exist with non-string values or MongoDB operator patterns in grant parameter fields
  4. Review audit logs for anomalous OAuth requests
    Search Rocket.Chat audit logs or HTTP access logs for requests to /oauth/token endpoints containing suspicious patterns like '{"$ne' or '$' characters in client_id, client_secret, or refresh_token parameters
    Affected if Suspicious /oauth/token requests with non-string parameter patterns are found in logs
  5. Check for unauthorized access tokens
    Query oauth_access_tokens for tokens created outside expected time windows or associated with unexpected client_id values, and verify which users own those tokens
    Affected if Access tokens exist that were not explicitly granted or were created through the exploitation pattern

A user is affected if running a Rocket.Chat version below 8.5.0 (or the other patched versions) with OAuth2 enabled, and either MongoDB contains anomalous tokens or audit logs show injection attempts.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Upgrade Rocket.Chat to version 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. Additionally, rotate all existing OAuth access tokens and refresh tokens since the server may have been compromised, and review audit logs for suspicious /oauth/token requests with non-string parameter patterns.

Recommended fix High confidence

Rocket.Chat 8.5.0 (or at minimum 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, or 7.10.11)

  1. Back up the Rocket.Chat database and configuration files before proceeding with the upgrade
  2. Stop the Rocket.Chat service to prevent data inconsistencies during upgrade
  3. Upgrade Rocket.Chat to version 8.5.0 (or at minimum one of the patched versions: 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, or 7.10.11)
  4. Restart the Rocket.Chat service after upgrade completes
  5. Verify the OAuth token endpoint no longer accepts MongoDB query operators by testing that invalid grant parameters are rejected
  6. Audit oauth_access_tokens collection to confirm no unauthorized tokens were created during the vulnerability window
  7. Rotate all existing OAuth tokens and session credentials as a precaution
  8. Review admin accounts and API keys for any unauthorized modifications
Caveat Major version upgrades (e.g., 7.x to 8.x) may introduce breaking changes; review release notes for migration requirements

Generated from the published advisory — verify against the referenced sources before acting.

Have this fixed Scoped from the published advisory
  • Consultation4.0 h
  • Implementation2.0 h
  • Testing4.0 h
  • Review / QA2.0 h
12.0 hours of engineering $2,120
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,392.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-45689 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-45689 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data