Exposed MongoDB (Port 27017)
detect, harden, and verify closure
Internet-facing MongoDB on TCP 27017 with no authentication enabled, weak authentication, an outdated build, or a permissive cloud security group is one of the most consistently exploited data-exposure paths in cloud, container, and on-premise estates. Tens of thousands of unauthenticated MongoDB instances have been wiped, ransomed, or copied in successive sweeps since 2017. Learn how to detect MongoDB exposure, lock it down, and keep the closure verifiable.
No credit card required. Free plan available forever.
What is exposed MongoDB?
Exposed MongoDB is the cluster of weaknesses that turn a MongoDB database into a direct data-breach and ransomware path. The most common shape is an internet-facing listener on TCP 27017 with security.authorization disabled, the deprecated enableLocalhostAuthBypass left on, the legacy SCRAM-SHA-1 mechanism still accepted, a bindIp setting that resolves to 0.0.0.0, no TLS encryption in transit, an outdated server build behind the upstream support window, or a permissive cloud security group that opens the port to the public internet during a migration that nobody narrowed back down.
Internal-only MongoDB instances are not safe by definition either. Lateral movement from a compromised application host, supply-chain compromise of a deploy pipeline, a vendor-managed jump server that reaches the wrong subnet, or a developer-built side instance that joins production by accident all read the same misconfigurations as a public attacker would. Sister exposures land on the same hosts: an internet-facing SSH listener is often what gives the attacker the foothold from which the open MongoDB instance gets enumerated.
The track record is unambiguous. The 2017 MongoDB ransomware sweep wiped or held tens of thousands of unauthenticated instances. The 2020 Meow attacks scripted indiscriminate deletion of exposed MongoDB, Elasticsearch, Redis, and Cassandra without even leaving a ransom note. CISA and the FBI continue to flag exposed database services among the leading initial access and data-theft enablers in joint advisories. Shodan and Censys index tens of thousands of MongoDB listeners on TCP 27017 at any moment, and the operators of those scans publish public dashboards. Adjacent neighbourhood exposures land on the same hosts as MongoDB: an exposed Docker socket on TCP 2375 or a mounted /var/run/docker.sock inside a CI runner gives the same attacker root-equivalent control of the host that often runs the database container in the first place.
Exposed MongoDB is also a recurring audit and cyber-insurance finding. PCI DSS Requirement 1.3, 2.2, and 8.3, ISO 27001 Annex A.5.15, A.8.5, A.8.20, A.8.21, A.8.24, and A.8.25, NIST SP 800-53 SC-7 and IA-2, the CIS MongoDB Benchmark, the CIS Critical Security Controls v8.1 Control 3 and Control 4, GDPR Articles 32 to 34, HIPAA 45 CFR 164.312, and most cyber insurance questionnaires either prohibit or restrict direct internet exposure of database services and require documented hardening of those that remain. Closing the exposure or hardening the listener is usually inexpensive compared to the operational, regulatory, and reputational cost of leaving it open, which is why this class of finding tends to move quickly through remediation tracking once it is surfaced on a controlled record.
How attackers exploit it
Discover open 27017
Attackers continuously scan IPv4 (Shodan, Censys, Masscan, ZMap, custom scanners) for hosts answering on TCP 27017 and the alternate 27018, 27019, and 28017 ports. The MongoDB wire protocol handshake reveals the server version, the storage engine, and whether authentication is required, often before any credential is submitted.
Probe authentication state
Tooling (mongo shell, mongosh, nmap mongodb-info, custom Go and Python clients) checks whether the listener accepts connections without credentials. Where authentication is off, the attacker lists databases, collections, indexes, and recent operations without ever submitting a username. Where authentication is on but weak, automated brute-force or credential-stuffing tooling replays leaked breach corpora.
Exfiltrate, ransom, or wipe
Once authenticated or where no credential is required, attackers run db.adminCommand({ listDatabases: 1 }), iterate the collections, copy the data to attacker storage, drop or rename the original collections, and leave a ransom note (a "README" or "PLEASE_READ" collection) demanding cryptocurrency for return. Meow-class attackers skip the ransom step and overwrite the database with random data.
Establish foothold and pivot
Where the MongoDB host is on the same network as application servers, attackers harvest credentials, configuration files, and JWT signing secrets stored in the database; abuse mongod insider commands such as $function and $accumulator on unpatched builds to achieve remote code execution; pivot through cluster keys to peer shard hosts; and stage ransomware deployment or large-scale data exfiltration through the same connection.
Common causes
Cloud security group rule too broad
An AWS security group, Azure NSG, GCP firewall rule, or DigitalOcean rule opens TCP 27017 to 0.0.0.0/0 during a Terraform run, a migration, a debug session, a vendor handoff, or a recovery exercise. The rule is never narrowed, and a public MongoDB listener persists across image rebuilds, autoscaling events, replica-set promotion, and account migrations.
security.authorization disabled
mongod is started with auth turned off, either by leaving the default configuration that ships with self-built containers and docker run examples, by setting security.authorization to disabled in /etc/mongod.conf for a local debug run that ends up in production, or by running mongod without the --auth flag. The first user connecting becomes a de facto admin.
bindIp set to 0.0.0.0 by default
Older MongoDB defaults bound to 0.0.0.0, and self-hosted deployments still inherit that pattern through legacy configuration files, container images, and Helm charts. Modern builds default to 127.0.0.1, but a single net.bindIp line in /etc/mongod.conf or a single MONGO_INITDB environment variable in a Compose file restores the broad bind quickly.
Outdated MongoDB build
Long-lived virtual machines, frozen container images, vendor-distributed appliances, and home-grown installs run a MongoDB release several years behind the upstream support window. End-of-life branches receive no security backports, and recent CVEs (including the 2024 unauthenticated-DoS class and the 2023 deserialisation and $function and $accumulator hardening) turn aged builds into immediate exposure events.
Default ports left advertised
mongod listens on 27017, mongos on 27017, configsvr on 27019, shardsvr on 27018, and the deprecated mongo-express dashboard often on 8081 or 8082 of the same host. Attacker tooling sweeps the full set; restricting one port without restricting the others leaves a covered side path open.
Weak or default credentials still accepted
security.authorization is on but the deployment still accepts default accounts (admin/admin, root/root, mongo/mongo, dba/dba) from a quickstart, a Helm chart, or a one-off recovery script. SCRAM-SHA-1 remains accepted alongside SCRAM-SHA-256, opening the listener to offline cracking of weak passphrases. x509, LDAP, and Kerberos integration that would constrain the credential surface is not configured.
How to detect it
Automated detection
- SecPortal's external scanner port-scan module probes TCP 27017 across every verified domain and host in scope, identifies the responding service as MongoDB through banner and protocol-handshake detection, and raises a critical-severity finding under the rule that database and cache services should never be directly exposed to the internet.
- Continuous monitoring re-runs the external scan on a schedule, so a security-group edit, a Terraform apply, a replica-set promotion, an autoscale event, or a recovered backup host that re-exposes 27017 reopens the finding rather than leaving the regression invisible until the next audit cycle.
- Bulk import accepts Nessus, Burp, and CSV output from network-tier scanners and from Shodan and Censys exports that already list exposed MongoDB instances, so the catalogue stays centralised even when a third-party tool is the original discovery source.
Manual verification
- Use nmap -p 27017,27018,27019,28017 with service detection (-sV) and the mongodb-info and mongodb-databases scripts against the external range to confirm the listener, the server version, the storage engine, and whether authentication is required.
- Run mongosh against each reachable listener to read the server build info, list databases, and confirm whether security.authorization is enabled. A successful db.adminCommand({ listDatabases: 1 }) without credentials is the definitive proof of an unauthenticated listener.
- Cross-reference the MongoDB build banner against the MongoDB Server release notes, the MongoDB security advisory page, and the CISA Known Exploited Vulnerabilities catalogue to identify whether any unpatched MongoDB CVE is present.
- Check Shodan and Censys for the organisation's netblocks and known hostnames to see whether external observatories already list exposed MongoDB instances and the banners they advertise, then reconcile that list against the verified-domain inventory inside the workspace.
How to fix it
Remove direct internet exposure
Block TCP 27017 (and 27018, 27019, 28017, plus any mongo-express dashboard port) inbound at the perimeter firewall, the cloud security group, and the load balancer for every host. There is no production scenario where a long-lived MongoDB listener should be reachable from 0.0.0.0/0. Reach the database through a private subnet, a VPC peering or PrivateLink endpoint, a managed bastion service, or a zero-trust access broker.
Enable security.authorization and remove anonymous access
Set security.authorization: enabled in /etc/mongod.conf (or pass --auth at startup). Remove the deprecated enableLocalhostAuthBypass. Disable any anonymous user-creation path that survives from the initial quickstart. Create the first admin user via the localhost exception, then close the exception. Confirm that mongosh without credentials returns Authentication failed.
Lock bindIp and listen interfaces
Set net.bindIp to the specific private interface MongoDB should answer on, never 0.0.0.0. For multi-host replica sets, list each peer interface explicitly. Pair the bind with a private VPC and a security group that allows only the application tier, the replica peers, and the backup runner to reach 27017. Apply the same restriction to mongo-express and any other admin UI.
Patch the MongoDB build
Apply MongoDB Server updates promptly, especially advisories naming the $function and $accumulator hardening, the 2023 deserialisation class, the 2024 unauthenticated DoS class, and the Atlas advisory feed. Move off end-of-life branches (3.x, 4.0, 4.2, and any pre-EOL line) onto a supported version before the upstream support window closes.
Enforce strong authentication mechanisms
Set authenticationMechanisms to SCRAM-SHA-256 only and disable SCRAM-SHA-1. Rotate any account that ever authenticated through SCRAM-SHA-1. For service accounts that connect from infrastructure, prefer x509 certificate authentication or MONGODB-AWS IAM authentication. For human operators, prefer LDAP or Kerberos federation tied to the workforce identity provider so leavers lose access in one place.
Enable TLS encryption in transit
Set net.tls.mode to requireTLS and provide a certificate signed by an internal certificate authority. Reject plaintext connections. Pair the TLS configuration with allowedHosts or x509 client-certificate enforcement so only authorised callers can complete the handshake. Audit driver versions to confirm every application client supports the modern cipher suite.
Apply role-based access control
Replace the broad root role with purpose-scoped roles (readWrite on a single database, dbOwner on a tenant database, clusterMonitor for monitoring, backup for the backup runner). Bind every application account to the smallest role bundle that lets it do its job. Audit the user list quarterly and remove accounts whose owning service or owning human has rotated.
Enable audit logging and monitoring
Turn on the MongoDB audit log (auditDestination, auditFormat, auditFilter) for authentication events, role grants, schema changes, and admin commands. Forward the audit stream to the SIEM or detection pipeline. Pair the listener with a brute-force detection rule for repeated failed authentication and a baseline rule for unexpected admin operations.
Operationalising the fix on the workspace
Closing an exposed MongoDB instance and hardening mongod is rarely the hard part for an experienced platform or database engineer. The operational hard part is keeping the closure intact across rebuilds, autoscaling, replica-set promotion, vendor migrations, mergers and acquisitions, and the long tail of cloud accounts and on-premise hosts that nobody currently lists in a primary asset inventory. The workspace pattern below is what AppSec, cloud security, vulnerability management, data security, and security engineering teams use to keep an exposed-MongoDB finding from coming back six months later under a new account or a renamed host.
Surface every MongoDB listener on one finding record
External scanning and bulk import land every exposed-MongoDB detection on the findings management record with CVSS, the discovered host, the captured banner, the server version, the scan timestamp, and the named owner so the catalogue is a single source of truth rather than a Shodan tab, a spreadsheet, and a Slack thread.
Inspect configuration drift through authenticated scans
Where the team has authorisation, the authenticated scanning path reads the responding service in more detail and pairs the result with the per-host hardening record. Credentials for authenticated runs live in encrypted credential storage scoped to a verified domain so the same database secret is not copied across spreadsheets, chat threads, and pull-request bodies.
Run remediation as a tracked workflow
Each finding flows through the remediation tracking workflow with severity, target close date, named owner, and the agreed compensating control (for example, an inbound source allowlist while the PrivateLink endpoint is provisioned, or a temporary firewall rule while authentication is stood up). Permanent exceptions enter the eight-field exception register with a named approver, a rationale, an effective period, and a renewal cadence.
Verify the fix with retest
Once the firewall rule, security-group edit, mongod.conf change, host retirement, or migration to Atlas private endpoint completes, the retesting workflow re-runs the external scan, confirms the listener is gone or that the responding service now requires authentication on a private interface, and stamps the closure with timestamped evidence rather than a verbal sign-off in a stand-up.
Catch regressions through continuous monitoring
Scheduled continuous monitoring re-scans of verified domains reopen the finding if MongoDB returns to the public internet, if the banner drops back to an end-of-life build, or if a new cloud account joins the estate with an open 27017. A Terraform apply, a replica-set promotion, an autoscaler refresh, or a recovered backup image does not silently reintroduce the exposure.
Pair with the broader exposure catalogue
Exposed MongoDB rarely shows up alone. The same host frequently exposes SSH misconfiguration, default credentials, cloud bucket misconfiguration, or sensitive data exposure. Treating MongoDB exposure as one finding inside a host-level posture review keeps the queue ordered against real residual risk rather than chasing isolated ports one at a time.
Carry the audit trail through closure
The activity log records who opened, scoped, remediated, and verified each exposed-MongoDB finding, so the next ISO 27001, SOC 2, PCI DSS, HIPAA, or cyber insurance review reads the operating evidence from the record rather than from reconstructed memory, archived ticket exports, or screenshots taken weeks after the fact. Where a breach-notification clock starts, the breach-notification workflow reads from the same record.
Communicate posture in leadership language
When database exposure sits inside a broader programme review, the Claude-drafted AI report composes a leadership-ready narrative from the open and closed findings, the remediation cadence, and the linked compliance evidence. The same record drives security leadership reporting without rebuilding the slide deck by hand each quarter.
Where the exposure usually lands
Exposed MongoDB is not a single shape across the enterprise estate. The conversation a cloud security team has with a platform team about a self-hosted replica set in a development VPC differs from the conversation a data security team has with an application team about an Atlas cluster reachable from the wrong peering route. The four contexts below are the most common landing places, and each one needs a slightly different remediation playbook surfaced on the same finding record.
Self-hosted MongoDB on cloud VMs
EC2, Compute Engine, Azure VM, and DigitalOcean droplet deployments of community-edition MongoDB make up the bulk of historic exposure events. Replace standing 0.0.0.0/0 security-group rules with private subnets, security-group source restrictions to application tiers, and managed bastion access for human operators. Move long-lived production workloads onto Atlas or another managed service where the network boundary is built in.
MongoDB Atlas with permissive IP allowlist
Atlas inherits the deployment defaults of whoever provisioned it. A 0.0.0.0/0 IP access list, a project-wide read role granted by accident, an unrotated programmatic API key, or a peering route that reaches the wrong VPC creates the same exposure pattern as a self-hosted listener. Bind every cluster to PrivateLink or VPC peering, enforce SCRAM-SHA-256 and x509 or AWS IAM for service callers, rotate programmatic API keys quarterly, and use the Atlas audit log as the source of truth for who connected when.
Containerised MongoDB in dev, test, and CI
Dockerised MongoDB instances inherit the official image defaults, environment-variable initialisation, and quickstart Compose files. A misrouted bridge network, a kubectl port-forward left running, an exposed service of type LoadBalancer, or an ingress-controller rule that catches more traffic than intended reopens 27017 quickly. Bake security.authorization on in the Helm chart, default to net.bindIp 127.0.0.1 in dev compositions, and treat any LoadBalancer service for a database as a finding to triage.
Legacy MongoDB on aged builds
Long-lived virtual machines, vendor-distributed appliances, customer-managed instances at acquired companies, and home-grown installs run a MongoDB release several years behind the upstream support window. End-of-life branches receive no security backports. Track these hosts on the finding record with the build identifier, the maintainer contact, and the upgrade path. Where the host cannot be upgraded immediately, isolate it behind a managed network access boundary and document the residual risk decision in the exception register.
Compliance impact
OWASP Top 10
A05:2021 - Security Misconfiguration; A02 - Cryptographic Failures
PCI DSS
Req. 1.3 / 2.2 / 8.3 - Boundary, Config, Strong Auth
ISO 27001
A.8.5 Secure Auth; A.8.20 Networks; A.8.24 Cryptography
NIST 800-53
SC-7 Boundary Protection; IA-2 Identification and Auth
CIS Controls v8.1
Control 3 Data Protection; Control 4 Secure Configuration
NIST CSF 2.0
PR.AA Identity Mgmt; PR.DS Data Security
SOC 2
CC6.1 Logical Access; CC6.6 Logical Access Boundary
GDPR
Article 32 Security of Processing; Article 33 Notification
Where MongoDB posture lands inside the team
Exposed MongoDB sits across several teams at once. The internal security team owns the policy, the audit response, and the breach-notification posture. The cloud security team owns the cloud-account perimeter, the security-group baseline, and the PrivateLink architecture. The data security team owns the encryption controls, the role bundles, and the audit-log review. The vulnerability management team owns the backlog, the prioritisation, and the SLA. The security engineering team owns the hardening tooling and the identity federation path. SecPortal keeps the same finding visible to all of them on the workspace record so the handoffs do not lose context as the work moves between owners.
Related features
Vulnerability scanning tools that map your attack surface
Test web apps behind the login
Monitor continuously catch regressions early
Vulnerability management software that tracks every finding
Verify fixes and track reopens on the same finding record
Bulk finding import bring your scanner data with you
Finding overrides that survive every scan cycle
Compliance tracking without a full GRC platform
Every action recorded across the workspace
AI-powered reports in seconds, not days
Find every exposed MongoDB instance across your estate before someone else does
SecPortal's external scanner probes TCP 27017 across verified domains, identifies responding MongoDB services, raises a critical-severity finding with port and service evidence, tracks remediation through closure, verifies the fix through retest, and re-runs continuously so a security-group edit, a Terraform apply, or a recovered backup image does not silently re-expose the database. Start free.
No credit card required. Free plan available forever.