Databases & Data Stores
Database admin tools, SQL dumps, and data-store endpoints probed for exfiltration.
21 probed paths in this category.
_all_dbs
MongoDB
Risk: This CouchDB endpoint lists every database on the server; if reachable without auth it confirms an open CouchDB instance and lets an attacker enumerate and then read or modify all databases.
Fix: Enable CouchDB authentication and require admin credentials, bind it to localhost or a private network, disable the admin party, and place it behind a firewall.
adminer.php
Adminer single-file database management tool
Risk: A single-file Adminer script with valid or guessable DB credentials grants full read/write access to MySQL, PostgreSQL, SQLite, or other backends, and older Adminer versions are vulnerable to SSRF and arbitrary file read.
Fix: Delete adminer.php from production webroots, keep Adminer updated, and if it must exist restrict access by IP allowlist plus server-level authentication rather than relying on DB login alone.
adminer/
Adminer database management tool directory
Risk: An Adminer directory exposes the same multi-database management console, allowing credential-based takeover of connected databases and exploitation of known SSRF or file-disclosure flaws in outdated builds.
Fix: Keep database management tools off public webroots, gate them behind VPN or IP restrictions and HTTP auth, update Adminer regularly, and serve a 404 for the path in production.
api/v1/clickhouse/query
ClickHouse Query API
Risk: An open ClickHouse HTTP query interface allows arbitrary SQL execution, and with the default credential-less 'default' user an attacker can dump tables, and certain table functions/configs enable reading local files or making outbound requests from the server.
Fix: Set passwords for all ClickHouse users including default, disable readonly bypass, restrict the HTTP/native ports via listen_host and firewall rules, and disable dangerous functions like file() for untrusted users.
api/v1/influxdb/query
InfluxDB Query API
Risk: An exposed InfluxDB query API lets an attacker read time-series metrics that often reveal infrastructure topology and business KPIs, and on unauthenticated instances run DROP queries to destroy measurements and databases.
Fix: Enable authentication and per-user/per-bucket tokens, serve the API over TLS, and bind InfluxDB to a private interface behind a firewall or proxy.
api/v1/mongo/admin/users
MongoDB Admin Users API
Risk: Reaching an admin users endpoint can expose database account names and roles, and an unauthenticated MongoDB instance allows full read/write access and credential or data exfiltration.
Fix: Enable MongoDB authentication and authorization, bind to localhost or a private subnet, and never expose admin databases or this route to the public internet.
api/v1/snowflake/warehouses
Snowflake Warehouses API
Risk: Leaked Snowflake API access or credentials lets an attacker enumerate warehouses and spin up compute that incurs direct billing cost, and query databases to exfiltrate large volumes of analytical and customer data.
Fix: Enforce MFA and key-pair authentication, apply network policies to allowlist IP ranges, scope warehouse and database access via least-privilege roles, and rotate any credentials found in client code or CI.
api/v1/timescaledb/metrics
TimescaleDB Metrics API
Risk: As a PostgreSQL extension, an exposed TimescaleDB endpoint inherits Postgres risk: with weak or default credentials an attacker reads hypertables of time-series data and can leverage SQL functions or COPY to access the host filesystem.
Fix: Enforce strong PostgreSQL role passwords and pg_hba.conf host restrictions, require TLS connections, and never expose port 5432 or any metrics proxy directly to the internet.
api/v1/trino/query
Trino Query API
Risk: An exposed Trino query API lets an attacker execute federated SQL across all connected catalogs (databases, object stores, lakes), reading or exfiltrating data from every backing data source the coordinator can reach.
Fix: Require authentication (LDAP, OAuth2, or JWT) and TLS on the Trino coordinator, enable system access control to scope catalogs per user, and restrict coordinator network access.
backup.sql
SQL Database Backup
Risk: A downloadable SQL dump exposes full table contents - including user records, password hashes, and any stored secrets - enabling offline credential cracking and complete data exfiltration.
Fix: Store database backups outside the webroot, restrict access with authentication, and serve them only via authenticated tooling rather than static HTTP.
backup/database.sql
Common SQL database-backup path probed for credential and data theft
Risk: A reachable SQL dump exposes the entire database, including user records, password hashes, and credentials, enabling complete data theft and account takeover.
Fix: Never store backups within the web root, restrict backup storage to access-controlled locations, encrypt dumps at rest, and return 404 for such paths at the web server.
config/database.php
PHP database-configuration file containing connection credentials
Risk: Exposes database hostname, username, and password in plaintext PHP, letting an attacker connect directly to the backend database to read, modify, or drop all application data, and potentially pivot to other services reusing those credentials.
Fix: Move credentials out of web-accessible directories into environment variables or a secrets manager, and configure the web server to deny direct requests for .php config files outside the front controller.
data/dump.sql
SQL dump file path probed for database exfiltration
Risk: A reachable SQL dump hands the attacker a full offline copy of the database including user records, password hashes, and internal schema, enabling credential cracking and targeted follow-on attacks without touching the live database.
Fix: Never store backups under the web root; keep dumps in an access-controlled location off the server and block requests for .sql files at the web server with a 404 or 403.
database.sql
SQL Database Dump
Risk: An exposed schema-plus-data dump reveals table structures and sensitive row data, letting an attacker map the application's data model and harvest credentials or PII for further attacks.
Fix: Keep .sql exports out of any web-accessible directory and add server rules denying direct requests for SQL files.
databricks/api/2.0/clusters/list
Databricks Clusters API
Risk: A valid Databricks token reaching this endpoint reveals all clusters and lets an attacker attach notebooks or jobs that run arbitrary code with the workspace's cloud IAM permissions, pivoting into the underlying AWS/Azure/GCP account and data lake.
Fix: Treat Databricks PATs as secrets with short TTLs, enable IP access lists and SSO/SCIM, use cluster policies and Unity Catalog for least privilege, and scope the instance profile/managed identity minimally.
db.sql
SQL database dump
Risk: A downloadable SQL dump exposes the entire database including user records, password hashes, and application secrets, enabling mass credential theft and offline analysis.
Fix: Never place database dumps in web-accessible directories, block .sql files at the server level, and store backups in access-controlled storage off the web host.
dbadmin/
Generic database administration interface path probed by scanners
Risk: If this resolves to a real database admin panel, an attacker can attempt credential reuse and brute force to gain SQL-level control of the backend, exfiltrate data, and pivot via file writes or stored procedures.
Fix: Avoid predictable admin paths, place any DB administration interface behind network restrictions and strong auth, and ensure scanners hitting this path receive a clean 404 with no stack trace or version banner.
dump.sql
SQL Database Dump
Risk: A publicly fetchable database dump hands an attacker the complete contents of the database, including authentication data and business records, for offline analysis and account takeover.
Fix: Move dump files to a non-public location with access controls and block .sql downloads at the web server level.
phpmyadmin/
phpMyAdmin web-based MySQL/MariaDB administration tool
Risk: An exposed phpMyAdmin instance lets an attacker brute-force or reuse MySQL/MariaDB credentials to read and modify all databases, run arbitrary SQL, and often write web shells via INTO OUTFILE or known phpMyAdmin RCE chains.
Fix: Do not deploy phpMyAdmin on internet-facing hosts; restrict it to localhost or a VPN, place it behind IP allowlists and HTTP auth, keep it patched, and rename or remove the default path.
pma/
Common alias path for phpMyAdmin database administration
Risk: This common phpMyAdmin alias gives the same database takeover as the canonical path - full SQL access to MySQL/MariaDB, credential brute-forcing, and potential file writes leading to remote code execution.
Fix: Remove unused phpMyAdmin aliases, bind admin tooling to internal networks only, enforce strong authentication and IP restrictions, and return a clean 404 for these paths on production.
redis/info
Redis Server Information
Risk: The INFO output leaks Redis version, memory, client, and persistence configuration, and an unauthenticated Redis allows arbitrary key access and CONFIG-based writes that can lead to RCE.
Fix: Set requirepass or ACLs, bind to localhost or a private network, disable or rename dangerous commands like CONFIG and SLAVEOF, and enable protected mode.