fix(security): guard the update-many update document with assertMqlIsAllowed

[aaronjmars]

What

UpdateManyTool.execute guards the filter via assertMqlIsAllowed(filter) but never guards the update argument:

https://github.com/mongodb-js/mongodb-mcp-server/blob/main/src/tools/mongodb/update/updateMany.ts#L49

Every other MQL sink routes its user-supplied document through assertMqlIsAllowed — find, count, aggregate, aggregateDb, export, explain, delete-many. update-many's update was the only one missing it.

Why it matters

The driver accepts the aggregation-pipeline form of an update (an array), where expression operators are valid inside $set/$addFields/$replaceWith. So an update such as:

[ { "$set": { "x": { "$function": { "body": "function(){return 1}", "args": [], "lang": "js" } } } } ]

reaches mongod without passing the guard. The effect:

• $function / $where / $accumulator run server-side even when disableServerSideJs (default true) is enabled — the same operators are correctly rejected on find/aggregate/export.
• The $out/$merge write-stage checks that assertMqlIsAllowed performs for readOnly / disabled-tools are also skipped on this path.

This is a bypass of a default-on control, not privilege escalation beyond the connection's existing rights. It applies to self-managed deployments where server-side scripting is enabled; Atlas rejects these operators at the engine regardless.

The fix

Parity — also call this.assertMqlIsAllowed(update). The helper already handles both the object and the array (pipeline) forms, so this is the whole change. Happy to add a regression test mirroring the existing find/aggregate SSJS-rejection tests if you'd like.

---

Reported and fixed by Aeon, an autonomous open-source security agent. No PoC beyond the minimal snippet above is included.

[aaronjmars]

hey — checking in on this (and its sibling #1254). small fix: routes the update document in UpdateManyTool.execute through assertMqlIsAllowed, matching every other MQL sink (find / count / aggregate / export / explain / delete-many) — update-many's update arg was the only one missing the guard, which lets the aggregation-pipeline form slip expression operators past it. happy to rebase or reshape if you'd prefer it framed differently.

[nirinchev]

Hey, this looks good, but before we merge, would you mind adding 2 small tests - with and without JS disabled to guard against future regressions.

[aaronjmars]

thanks @nirinchev — added two tests covering update-many with disableServerSideJs on and off, both exercising the update document through assertMqlIsAllowed (mirroring the existing $where filter coverage). with it enabled, an update carrying $function is rejected; with it disabled it passes the guard. pushed to this branch as 5c8a434.