GHSA-mh5c-679w-hh4r

What it actually does

A denial-of-service flaw in the mongodb npm driver allows crafted input or malformed driver operations to trigger unhandled errors that crash or hang the Node.js process. Database connectivity and any in-process work sharing that runtime are lost until the application is restarted. Confidentiality and integrity of data are not the primary effects; availability of the driver and the hosting service is.

Why it matters to the business

Services that talk to MongoDB through this driver can go offline without warning, interrupting user traffic, background jobs, and transactions until operators restart them. The package has 61 known downstream dependents, so the outage risk can appear through transitive dependencies, not only direct use. The advisory is old (published 2020-09-03) and is not in CISA KEV, with exploit maturity reported as none, but unpatched production apps remain easy targets for availability disruption.

How an attack unfolds

An attacker finds an application that uses a vulnerable mongodb npm driver (before 3.1.13) and can influence data or options the driver processes—typically via an exposed API, job payload, or other untrusted input that reaches MongoDB client calls. They send input that drives the client into an error path the old driver does not handle, causing the Node.js process to abort or stop serving requests. No named threat actors or ransomware campaigns are associated with this issue. Impact is process-level downtime rather than data theft or persistent access.

How to fix it

Upgrade the mongodb npm package to 3.1.13 or later on every direct and transitive consumer. Pin and rebuild lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) so older 3.1.x builds cannot be reintroduced. Redeploy so running processes load the patched driver. If an immediate upgrade is blocked, reduce exposure by keeping untrusted input away from driver APIs and placing the service behind rate limits and process supervisors, then complete the version upgrade as the real fix.

How to confirm the fix worked

Run a dependency inventory (for example npm ls mongodb, yarn why mongodb, or lockfile review) and confirm every resolved mongodb npm version is 3.1.13 or newer. Rebuild and redeploy, then verify the running image or node_modules tree no longer contains pre-3.1.13 builds. Exercise normal database connect, query, and write paths in staging and confirm the process stays up. Treat any remaining mongodb@<3.1.13 in CI or production lockfiles as unfixed exposure.

Typical attack path

1. Identify an application or package that depends on the mongodb npm driver before 3.1.13, including via transitive dependencies.
2. Reach a code path that constructs MongoDB operations from attacker-influenced input (HTTP handlers, queues, or similar).
3. Submit input that triggers an unhandled error or resource-exhausting condition in the vulnerable driver.
4. Observe the Node.js process crash, hang, or stop handling database work.
5. Repeat as needed to keep the service unavailable after restarts.

How to detect it

This issue causes crashes and restarts rather than a distinct implant, and no in-the-wild campaign is reported. Hunt historically around deploy windows that still ran mongodb npm before 3.1.13. Review Node.js/application logs for uncaught exceptions and fatal errors originating in the mongodb driver, process supervisor restart storms, sudden drops in MongoDB client connections, and APM traces showing the process exiting during driver calls. Correlate host or container restart counts with traffic that reached database-backed endpoints. Lockfile or SBOM evidence of mongodb < 3.1.13 shows exposure, not proof of exploitation.

• MongoError
• MongoNetworkError
• MongoTimeoutError
• uncaughtException
• unhandledRejection
• mongodb/lib/
• node_modules/mongodb/
• npm:mongodb@3.1.
• "mongodb": "3.1.12"
• "mongodb": "3.1.11"
• "mongodb": "3.1.10"

What your security team should do

• Inventory all applications and images that resolve mongodb (npm) and flag any version older than 3.1.13, including transitive dependents.
• Patch and redeploy to mongodb (npm) 3.1.13 or later; fail CI if lockfiles regress.
• Ensure process managers restart crashed Node services and that availability alerts fire on crash loops.
• Prioritize internet-facing and high-traffic services first; remaining risk is availability, not known mass exploitation.
• Track downstream packages among the 61 dependents so upgrades are not undone by nested pins.