Loading vulnerability…
Incomplete Role Cleanup in MongoDB Server
MongoDB Server user management commands use incorrect internal query predicates when dropping database roles. The operation removes role definitions but leaves stale role references in user and role documents. Subsequently recreating a role with the same name and different privileges can cause previously associated users to inherit those privileges without an explicit grant or corresponding grant audit event. Affected versions are 7.0.0 before 7.0.48, 8.0.0 before 8.0.37, 8.3.0 before 8.3.16, and 9.0.0 before 9.0.7.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Previously associated users can acquire unintended privileges when a deleted role name is reused, potentially resulting in privilege escalation and unauthorized database operations within the recreated role's permissions. The absence of a corresponding grant audit event reduces visibility into the effective authorization change.
If you can’t patch tonight, do this now.
No vendor-confirmed workaround is specified. Interim precautions include avoiding reuse of dropped role names, reviewing user and role documents for stale references after role deletion, and restricting database administrative privileges to trusted administrators.
Patch, then assume compromise.
Upgrade MongoDB Server to 7.0.48, 8.0.37, 8.3.16, or 9.0.7, or a later fixed release in the corresponding branch. Review user and role authorization assignments for stale references and unintended privileges; do not assume an upgrade alone corrects preexisting authorization inconsistencies.
No public exploits tracked yet. Mallory keeps watching.
4 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.