The EPSS score of 0.00302 badly understates the real risk here. This is a query subsystem crash — the hot path that every authenticated read operation traverses — triggered by a specially formed query filter. The authentication requirement isn't a meaningful mitigation; read-only users are typically the most liberally provisioned accounts in MongoDB deployments, granted to third-party integrations, BI connectors, and reporting tools outside the security perimeter. A user with legitimate read access can crash the server, and the CVE provides no specifics on which query patterns trigger the crash.
The operational blast radius in replicated deployments is the critical concern that neither CVSS nor EPSS captures. When a primary crashes, replica set elections trigger — during that window, writes queue or fail, and applications using primary read preference lose consistency guarantees. If this is a recurring class of bug in the query subsystem (and MongoDB's history suggests it may be), an attacker can crash nodes sequentially without elevated privileges.
The partial disclosure is a significant defensive gap. Without knowing which query patterns trigger the crash, you cannot implement application-layer workarounds or input validation. You're forced into binary responses — patch everything or assume the worst — without targeted mitigation options.
Prioritize patching in production. If you're running sharded clusters, plan for coordinated rolling restarts across shard nodes, config servers, and mongos routers; this process can take hours in large deployments. Treat this as a high-availability concern, not just a security patch.