---
title: "Find Exposed Databases"
canonical: https://trickest.com/library/exposed-database-scanner
description: "Port-scan a range for eight database engines and check every open service for unauthenticated access, from MongoDB and Redis to PostgreSQL."
---

# Find Exposed Databases

## Overview

A database reachable from the internet without authentication is not a
vulnerability you exploit. It is a database you read. There is no chain to build
and no payload to land, which is why these turn up in breach write-ups so often:
a container published a port it should not have, a managed service was created
with an open network policy, a test instance outlived the test.

Finding the open ports is the easy half. The question you actually have is which
of them matters, and a port list does not answer it. This run sorts a range into
the two states that decide your afternoon: a database port that demands
credentials, and one that answers to anybody who connects. It checks eight
engines at once rather than one at a time, names the engine behind each open
service, and groups what it finds by severity, so the first item in the report is
the first thing to fix and the rest is an inventory you can hand to whoever owns
the host. Scheduled against your own space, it belongs in
[exposure management](/use-cases/exposure-management) as a recurring check, since
this failure is usually introduced by a deploy rather than discovered in one.

## Pipeline

1. Read the targets, normalize them to IPs or CIDRs, and cap the range.
2. [rustscan](/tools/rustscan) scans the eight database ports across each batch,
   distributed over the fleet.
3. Open services are parsed out as `ip:port` pairs.
4. [nuclei](/tools/nuclei) TCP templates check each open service for
   unauthenticated access.
5. Anything on the MongoDB port additionally gets a dedicated CVE-2025-14847
   probe.
6. Findings collect into one report, grouped by engine and severity.

## Inputs

- **Targets.** One per line, as an IP, a CIDR, a hostname, or a host list. The
  safe default is the reserved documentation range `192.0.2.1/32`, where nothing
  is routed and nothing answers, so a first run exercises the graph and returns
  an empty inventory. Replace it with a range you own before you expect results.
- **Ports.** The eight database ports scanned by default: MongoDB 27017, Redis
  6379, Elasticsearch 9200, CouchDB 5984, Cassandra 9042, Memcached 11211,
  PostgreSQL 5432, MySQL 3306. Edit the list to widen coverage.
- **Range caps.** A safety limit rather than a setting you tune. CIDRs wider
  than `/16` are skipped and the host count is capped, so a mistyped target
  cannot become an internet-wide sweep.

## Outputs

- A PDF report that separates the two states you have to triage on: services
  that are reachable but still ask for credentials, and services that answer a
  connection anonymously. The second group is ranked first, grouped by engine and
  severity, and the methodology behind each finding is printed with it.
- The full `host:port` inventory of open database services, grouped by engine.
  When nothing answers anonymously this inventory is the finding, since it is
  proof of a clean database footprint.
- Unauthenticated-access findings per open service, in JSON lines, from the
  nuclei TCP templates. This is the record that turns a reachable port into a
  confirmed exposure.
- A MongoBleed probe result for every open MongoDB port, recording what was
  tried and what came back.

## Sample output

Illustrative output on TEST-NET documentation addresses. Nothing answers on those
ranges, so this shows the shape of each stage rather than somebody's exposed
database.

Open database ports are parsed into targets for the auth check:

```jsonl
{"ip": "192.0.2.1", "port": 27017, "engine": "mongodb", "auth_required": false, "severity": "critical"}
{"ip": "192.0.2.5", "port": 6379, "engine": "redis", "auth_required": false, "severity": "critical"}
{"ip": "192.0.2.10", "port": 9200, "engine": "elasticsearch", "auth_required": true, "severity": "info"}
{"ip": "192.0.2.23", "port": 5432, "engine": "postgresql", "auth_required": true, "severity": "info"}
{"ip": "192.0.2.41", "port": 27017, "engine": "mongodb", "cve": "CVE-2025-14847", "auth_required": false, "severity": "critical"}
{"ip": "192.0.2.55", "port": 3306, "engine": "mysql", "auth_required": true, "severity": "info"}
```

The MongoDB probe reports what it tried and what it found:

```json
{
  "scan_time_start": "2026-07-31T14:42:32.744556Z",
  "scan_time_end": "2026-07-31T14:42:37.759412Z",
  "cve": "CVE-2025-14847"
}
```

Against a real range, an engine that answers without credentials is reported with
the port and the service behind it. Nothing is read from the database itself.

## FAQ

### How do you confirm an exposure without pulling data out of it?

The check stops at the handshake. A TCP template opens a connection, observes
that the engine accepts it without asking for credentials, and records that fact.
No collection is listed, no key is fetched, no row is read. What you hand to the
host owner is the proof that authentication is absent, not a copy of what it was
protecting.

### What happens if I run it on the default target?

Nothing gets scanned. The default is a reserved documentation range with no hosts
behind it, so the run completes and the inventory comes back empty. Point it at a
range you own to get findings.

### Which engines does it cover?

Eight by default: MongoDB, Redis, Elasticsearch, CouchDB, Cassandra, Memcached,
PostgreSQL and MySQL. Add ports to the list to cover engines outside that set.

### Is it safe to point at production?

The template selection excludes intrusive, fuzzing and denial-of-service checks
along with informational noise, and both rate and concurrency are capped. Every
step is read-only.

### How large a range can I give it?

CIDRs wider than `/16` are skipped and the host count is capped, so a typo cannot
turn into an internet-wide sweep. Split anything bigger across several runs.

## Related workflows

- [ASN-Wide Vulnerability Scan](/library/asn-vulnerability-scanner). Reach for this
  instead when you want the whole CVE and web surface of the range assessed, not
  only the data stores sitting in it.
- [Passive Port & CVE Scan (Shodan)](/library/shodan-threat-intelligence). Reach for
  this instead when you are not allowed to send packets at the target and need
  the exposure picture from data somebody else already collected.
- [Cloud Bucket Finder (S3, GCS, Azure)](/library/cloud-bucket-finder-s3-gcs-azure).
  Reach for this instead when the data you are worried about is parked in object
  storage rather than in a database process on a port.

---
_Markdown source of https://trickest.com/library/exposed-database-scanner._