CVE-2026-18698

CVE-2026-18698 is a privilege boundary flaw in MongoDB's database-scoped role model that allows authenticated users with limited, database-scoped roles to access PROTECTED system collections — specifically those managing users, roles, indexes, and cluster topology. This is not a privilege escalation in the traditional sense; a database-scoped role is functioning exactly as assigned, yet MongoDB incorrectly interprets its scope boundaries at the collection level, granting access to system metadata the role should never reach. The vulnerability has two distinct risk dimensions. First, metadata exposure: index definitions, shard keys, and collection schemas reveal how your data is distributed and accessed — intelligence that enables targeted lateral movement or denial-of-service against specific shards. Second, conditional modification: under certain deployment configurations (replica set topologies, auth schema versions, or feature flags), the same scoping flaw permits writes to collections that should be immutable to database-scoped principals. The conditional nature is itself a warning sign — it suggests the scoping logic was implemented as deployment-specific branches rather than a uniform enforcement model, meaning the flaw likely exists latently across more configurations than the reported exploit path implies. What you should do: audit all database-scoped role assignments and verify which system collections they can currently reach — particularly system.users, system.roles, and system.indexes. If your deployment uses replica sets or sharding, test whether the modification condition applies to your topology. Apply the patch, but anticipate potential regressions: legitimate cross-database administrative workflows may break if they relied on the incorrect scoping behavior. Monitor for configuration drift post-patch, as the fix likely tightens privilege evaluation in ways that could surface unexpectedly in edge-case workflows. The EPSS score of 0.00168 reflects low opportunistic exploitation, but this shouldn't create complacency in multi-tenant environments where untrusted principals hold constrained roles — that's precisely the use case where this boundary violation becomes exploitable through intended functionality rather than circumvention.

Reviewed through automated stages and approved by a human before publication.