Disable MongoDB server-side JavaScript

The fix/etc/mongod.conf

security:
  javascriptEnabled: false

sudo systemctl restart mongod

Why it matters

MongoDB can evaluate JavaScript as part of a query. $where takes a JS expression, $function and $accumulator run JS in aggregation pipelines, and mapReduce is JS by definition.

The risk is injection. An application that interpolates user input into a $where clause has handed the user a JavaScript expression evaluated by the database:

// application code — the bug
db.users.find({ $where: `this.name == '${userInput}'` })

Input of ' || true || ' makes the predicate always true and returns every document, authorization checks on the query notwithstanding. Input containing a while(true) loop consumes a server thread — a denial of service from a search box.

Turning JS off removes the operator entirely. There is nothing to inject into.

Be honest about what this is not

This is not remote code execution on the host, and a lot of writing implies it is.

MongoDB runs this JavaScript in an embedded SpiderMonkey interpreter with no filesystem access, no network access, and no shell. An attacker who injects into $where gets to evaluate an expression against documents and burn CPU. They do not get a shell, they cannot write a file, and there is no equivalent of Redis’s CONFIG SET dir or MySQL’s UDF path.

So the realistic outcomes are query-logic bypass and denial of service — both real, neither a host compromise. That’s why this is medium and not critical, and why it sits below authorization, binding and roles on the list. Fix those first.

You are probably not using it

The reason this is an easy win: $where and mapReduce are slow, can’t use indexes well, and have been discouraged by MongoDB for years. The aggregation framework replaced mapReduce — MongoDB deprecated it in 4.4 — and query operators cover nearly everything $where was used for.

Most applications written in the last several years use none of it, so this is usually a free removal. Check rather than assume, but expect to find nothing.

Verify it worked

Confirm it’s off on the running server:

db.adminCommand({ getCmdLineOpts: 1 }).parsed.security

Expect javascriptEnabled: false.

Then prove it — this must fail:

db.foo.find({ $where: "return true" })

Expect:

MongoServerError: $where is not allowed in this atlas tier / no globalScriptEngine

The exact message varies by version; what matters is that it errors rather than returning documents.

Before you disable it, find out if anything uses it. Turn on the profiler briefly and grep for the operators:

db.setProfilingLevel(2)
// ...let the application run...
db.system.profile.find({
  $or: [
    { "command.filter.$where": { $exists: true } },
    { "command.pipeline.$function": { $exists: true } },
    { "command.mapReduce": { $exists: true } }
  ]
}).count()
db.setProfilingLevel(0)

Zero means this change is free. Also grep your application source — a $where that runs once a month won’t show up in a profiling window:

grep -rIn '\$where\|mapReduce\|\$function\|\$accumulator' /path/to/app

Before you apply this

Low risk, with one specific breakage: anything using $where, $function, $accumulator or mapReduce stops working, and the error appears at query time rather than startup — so it lands in a request, not in your deploy.

The profiler and grep checks above are the whole precaution. If they come back empty, this is a free change.

If something does use it, the fix is usually to rewrite the query rather than to leave JS enabled. A $where predicate almost always has a native equivalent that is both safer and dramatically faster, because native operators can use indexes and $where cannot. mapReduce has an aggregation-pipeline equivalent and has been deprecated since 4.4 — anything still using it is due a rewrite for reasons beyond security.

Don’t leave JS on just because one legacy report needs it. Rewrite the report. Leaving the operator available server-wide so that one monthly job works means every injection bug in every code path stays exploitable.

Note this is a mongod-wide setting — there is no per-database or per-user granularity.

Related

• Grant least privilege roles — bounds what an injected query can reach.