Context

SERVER-128089 audited aggregation-stage internal-only mechanisms. The scope was aggregation stages, with only a light sweep of the aggregate command's own options.

We should now do the analogous audit for command fields broadly, rather than only aggregation-stage fields.

Goal

Audit server command request fields/options across commands for places where an external client can set a field that is intended to be internal-only, router-only, server-only, or otherwise trust-boundary-sensitive.

Scope

Audit command request parsing/IDL for commands beyond the aggregation-stage surface, focusing on:

• command fields that are only meant to be set by internal clients, mongos, mongod, repl/sharding internals, or server-generated reparse/translation flows

• fields that skip or alter translation/planning/rewriting behavior

• fields that affect namespace routing, execution mode, privilege assumptions, or internal metadata propagation

• fields accepted through ad hoc parsing, not just IDL-marked options

This should include both:

• commands whose fields are parsed directly in command code

• command options that feed later internal execution paths and may currently trust user-supplied input too much

What the audit should answer

For each candidate field/option audited:

• Is it user-settable today?

• Is it intended to be internal-only or otherwise gated by client type?

• If an external client sets it, what happens?

• Does it cause wrong results, information disclosure, privilege boundary confusion, invariant/tassert failure, crash, or other security-sensitive behavior?

• Should the field be rejected at parse time, ignored, or explicitly documented as externally allowed?

Expected deliverables / acceptance criteria

• The audit covers the major server command surfaces and records what was checked

• An inventory of audited command fields/options and their classification

• A short write-up of any findings with severity notes / repro notes where relevant

• Any confirmed issues have follow-up tickets filed and linked from this ticket

• Negative test coverage for any confirmed fixes, especially for parse-time rejection of internal-only fields supplied by external clients

Suggested approach

Use the SERVER-128089 audit style as the model:

• enumerate commands with internal-looking or trust-sensitive fields

• inspect both IDL and non-IDL parsing paths

• prioritize fields that influence routing, repl/sharding internals, execution mode, translation, or server-generated intermediate representations

• for findings, prefer fail-closed parse-time validation where appropriate rather than relying on downstream behavior to make the input harmless