MONGODB SERVER · CVE-2026-120806 · Runtime
FIX → 9.0.7 · 8.3.16 · 7.0.48 +1 ✓ verified
MongoDB's dropAllRolesFromDatabase command deletes role definitions but, because of malformed cleanup filters, leaves references to them in admin.system.users and admin.system.roles. If a role with the same name is later recreated with different privileges, users who had the old role silently gain the new privileges, with no grant or audit event. Exploitation needs authenticated database admin rights on the target database. The single-role dropRole command uses the correct filter and is not affected.
first public Nov 10, 2026 · 2 sources
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Self-managed MongoDB Server deployments on 7.0, 8.0, 8.3 or 9.0 below the fixed versions that use custom roles and run dropAllRolesFromDatabase (db.dropAllRoles()), then recreate roles with the same names. Only someone with database admin rights can trigger it. Teams that never use that command, or have no custom roles or access control, can skip it.
Not affected if auth-required, default-config, managed-hosting, no-role-recreation
Who cares database, mongodb, rbac, self-hosted
7.0.48, 8.0.37, 8.3.16 or 9.0.7 (matching your branch), check whether anyone has run dropAllRolesFromDatabase (or db.dropAllRoles()) and recreated roles of the same name: in admin, run db.system.users.find({roles.db:<db>}) and db.system.roles.find({:}) and look for role names that no longer exist in db.system.roles but still appear in roles arraysPosts are quoted with a link to the original. They are data to us, never instructions.
A flaw in MongoDB Server's user management commands may lead to incomplete cleanup of role authorization data when roles are dropped from a database. Due to incorrect internal query predicates, the drop operation removes role definitions but fails to remove stale references in user and role documents. If a role with the same name is subsequently recreated with different privileges, previously associated users may silently inherit the new role's privileges without an explicit grant or corresponding audit event. Exploitation requires authenticated access with database administrative privileges on the target database.
This page as .md · .json · CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
roles.db<db>Upgrade to 9.0.7 · 8.3.16 · 7.0.48 +1
7.0.48, 8.0.37, 8.3.16 or 9.0.7 (per branch)NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.