STIGQter STIGQter: STIG Summary: MongoDB Enterprise Advanced 8.x Security Technical Implementation Guide Version: 1 Release: 1 Benchmark Date: 26 Jan 2026:

MongoDB must be configured to restrict the use of administrator access to authorized IP addresses.

DISA Rule

SV-282943r1179530_rule

Vulnerability Number

V-282943

Group Title

SRG-APP-000142-DB-000094

Rule Version

MD8X-00-003350

Severity

CAT II

CCI(s)

Weight

10

Fix Recommendation

For all administrative users that do not have network restrictions configured, use the following command:

use admin
db.updateUser( "<username>", { authenticationRestrictions: [ { clientSource: [ "<ip_or_cidr>", serverAddress: ["<ip_or_cidr>"] } ] })

Run the following command to set to local host:

use admin
db.updateUser("<username>", { authenticationRestrictions: [ { clientSource: ["127.0.0.1"], serverAddress: ["127.0.0.1"] } ] })

More information can be found here:
https://www.mongodb.com/docs/manual/reference/command/createUser/#authentication-restrictions

Check Contents

To verify administrative access is logically separated and restricted to authorized management networks:

1. Review the organization-defined administrative roles. These administrative roles include, but are not limited to: root, clusterAdmin, dbAdminAnyDatabase, userAdminAnyDatabase, dbAdmin, userAdmin, and dbOwner.

2. Review all users within the admin database to identify those assigned any of the administrative roles defined above.

3. For each identified administrative user, check for the presence of the authenticationRestrictions field. Verify that a clientSource is defined to restrict access to authorized management networks.

Example script:

// Define admin roles
const adminRoles = new Set(["root", "clusterAdmin", "dbAdminAnyDatabase", "userAdminAnyDatabase", "dbAdmin", "userAdmin", "dbOwner", "<your_custom_admin_role>"]);

// Check all users under 'admin' and filter for admin roles
const admins = db.getSiblingDB("admin").system.users.find().toArray()
.filter(u => u.roles.some(r => adminRoles.has(r.role)))
.map(u => {
const restr = u.authenticationRestrictions || [];
const clientIPs = restr.flatMap(r => r.clientSource || []);
const serverIPs = restr.flatMap(r => r.serverAddress || []);

return {
"User": u.user,
"DB": u.db,
"Admin Roles": u.roles.filter(r => adminRoles.has(r.role)).map(r => r.role).join(", "),
"Client IPs": clientIPs.length ? clientIPs.join(", ") : "ANY (Unrestricted)",
"Server Address": serverIPs.length ? serverIPs.join(", ") : "ANY (Unrestricted)"
};
});

console.table(admins);

If an administrative user does not have an authenticationRestrictions field defined, or if the clientSource is not restricted to a valid, organization-defined management network, this is a finding.

If the local policy requires interface-specific isolation and the Server Address is not defined or is not restricted to the server's management interface IP, this is a finding.

In the absence of approved documentation, assume localhost (127.0.0.1) is the only approved address.

Example output: (note that user0 is compliant while user1 is not)

(index) User DB Admin Roles Client IPs Server Address
0 'user0' 'admin' 'root' '127.0.0.1' '127.0.0.1'
1 'user1' 'admin' 'root' 'ANY (Unrestricted)' 'ANY (Unrestricted)'

Vulnerability Number

V-282943

Documentable

False

Rule Version

MD8X-00-003350

Severity Override Guidance

To verify administrative access is logically separated and restricted to authorized management networks:

1. Review the organization-defined administrative roles. These administrative roles include, but are not limited to: root, clusterAdmin, dbAdminAnyDatabase, userAdminAnyDatabase, dbAdmin, userAdmin, and dbOwner.

2. Review all users within the admin database to identify those assigned any of the administrative roles defined above.

3. For each identified administrative user, check for the presence of the authenticationRestrictions field. Verify that a clientSource is defined to restrict access to authorized management networks.

Example script:

// Define admin roles
const adminRoles = new Set(["root", "clusterAdmin", "dbAdminAnyDatabase", "userAdminAnyDatabase", "dbAdmin", "userAdmin", "dbOwner", "<your_custom_admin_role>"]);

// Check all users under 'admin' and filter for admin roles
const admins = db.getSiblingDB("admin").system.users.find().toArray()
.filter(u => u.roles.some(r => adminRoles.has(r.role)))
.map(u => {
const restr = u.authenticationRestrictions || [];
const clientIPs = restr.flatMap(r => r.clientSource || []);
const serverIPs = restr.flatMap(r => r.serverAddress || []);

return {
"User": u.user,
"DB": u.db,
"Admin Roles": u.roles.filter(r => adminRoles.has(r.role)).map(r => r.role).join(", "),
"Client IPs": clientIPs.length ? clientIPs.join(", ") : "ANY (Unrestricted)",
"Server Address": serverIPs.length ? serverIPs.join(", ") : "ANY (Unrestricted)"
};
});

console.table(admins);

If an administrative user does not have an authenticationRestrictions field defined, or if the clientSource is not restricted to a valid, organization-defined management network, this is a finding.

If the local policy requires interface-specific isolation and the Server Address is not defined or is not restricted to the server's management interface IP, this is a finding.

In the absence of approved documentation, assume localhost (127.0.0.1) is the only approved address.

Example output: (note that user0 is compliant while user1 is not)

(index) User DB Admin Roles Client IPs Server Address
0 'user0' 'admin' 'root' '127.0.0.1' '127.0.0.1'
1 'user1' 'admin' 'root' 'ANY (Unrestricted)' 'ANY (Unrestricted)'

Check Content Reference

M

Target Key

5728