Info

Summary A denial-of-service vulnerability exists in MongoDB server's query planner. A client that can issue find(...).sort(...) queries against a collection with a suitable compound index can supply large $in arrays that cause QueryPlannerAnalysis::explodeForSort() to overflow its size_t scan-count estimate. The wrapped value bypasses the maxScansToExplode safety check, after which makeCartesianProduct() materializes an enormous Cartesian product and can drive mongod into resource exhaustion and service unavailability. Details Vulnerable area: src/mongo/db/query/planner_analysis.cpp explodeForSort() multiplies point-interval counts into numScans without overflow checks totalNumScans is compared to the safety limit only after unchecked arithmetic With eight $in predicates of 256 values each, 256^8 = 2^64 wraps to 0 on 64-bit size_t Planning then proceeds into explodeNode() / makeCartesianProduct(), causing practical resource exhaustion Impact An authenticated client with query capability against a collection that has a suitable compound index can trigger unbounded resource consumption through a single crafted query shape. Observed result: service unavailability of mongod. Depending on memory limits, the effect may be process termination, OOM kill, or prolonged unresponsiveness. Evidence Control case using 200 values per $in array correctly set queryPlanner.maxScansToExplodeReached=True and kept the service alive Overflow-sized query caused connection drop, failed post-query TCP/ping checks, and container exit Affected versions Severity High (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) Reference Private report gist: https://gist.github.com/YLChen-007/e2baaa02f631dafb4d5ad88bb03f1692

Top User Comments

Steps to Reproduce

1. Start a MongoDB server running the affected code path. 2. Create or use a collection with a compound index matching {f1:1, f2:1, f3:1, f4:1, f5:1, f6:1, f7:1, f8:1, sortField:1} . 3. Issue a normal find(...).sort(...) query with eight $in predicates, each containing 256 point values. 4. Observe planner math wraps: 256^8 = 2^64 -> 0 on 64-bit size_t. 5. Observe that the safety guard is bypassed and planning proceeds into Cartesian-product materialization. 6. Result: client disconnects and mongod becomes unavailable. Control case Repeat with 200 values per $in array. Expected behavior: queryPlanner.maxScansToExplodeReached=True and server remains healthy. Artifacts Report: https://gist.github.com/YLChen-007/e2baaa02f631dafb4d5ad88bb03f1692