blueredix logo
SCAN On-demand vulnerability scans from €149
info service-database-cve

Vulnerabilities in databases (MySQL, PostgreSQL, MongoDB, Redis)

A database CVE matters not because of the service itself but because of what runs in the database. The "exposed to the internet" question is more important than the CVE list.

The headline question

When the scanner reports a CVE in a database server, the relevant question is rarely “is this bug serious?” — it’s “why is this database reachable from where the scanner reached it from?”

Production databases should not be on the public internet. Period. The historic record on this is brutal:

  • MongoDB ransomware sweeps of 2017–2019. Tens of thousands of internet-exposed MongoDB instances with default-no-authentication had their data dropped and replaced with ransom notes. None of those required a CVE.
  • Elasticsearch open-cluster leaks. Same pattern with Elasticsearch / Kibana. Multi-billion-record breaches at vendors who left port 9200 open.
  • Redis for cryptojacking. Open Redis has been used to drop miners onto servers via a config-and-save trick for nearly a decade.
  • MySQL on port 3306 with weak passwords — credential-stuffing campaigns against exposed MySQL accounts continue to this day.

If the scanner found your database from outside your network, fixing the CVE is the second job. The first is moving the database off the public internet — bind it to a private interface, put it behind a VPN, restrict by IP firewall.

Notes by database

  • PostgreSQL. Small CVE list, mature codebase, security releases are timely and well-documented. Most PostgreSQL CVEs are authenticated bugs (privilege escalation between roles) reachable only with a valid login. Pre-authentication bugs are rare. Check the version against postgresql.org/support/security/.
  • MySQL / MariaDB. Long CVE history. Most affect specific storage engines or features that may not be in use; read the advisory carefully to see whether your configuration is actually vulnerable. Oracle’s quarterly Critical Patch Update is the canonical source for MySQL.
  • MongoDB. Smaller CVE list, but configuration beats CVEs as a risk factor here. Bind to localhost or a private network, set authentication, enable role-based access. Default configurations on MongoDB < 3.6 had no authentication; modern versions require it.
  • Redis. Same story. The 2022 Lua sandbox escape (CVE-2022-0543) was the rare in-protocol RCE; most Redis incidents are configuration-based — protected-mode no, no requirepass, reachable from the internet.
  • Microsoft SQL Server. Patch Tuesday-driven. Stay current. Be wary of xp_cmdshell enabled by default in legacy installs.

When patching, check what’s actually running

The blueredix scanner reads the version from the database’s protocol handshake — that’s the server version, not necessarily the patched version on a distribution-managed install. The same caveat as for OpenSSH and web servers applies: if your PostgreSQL or MySQL came from your operating system’s package manager, look at the distribution’s security tracker rather than the upstream version’s CVE list.

For MongoDB, Redis, Elasticsearch installed from upstream packages or Docker images, the version is the version, and you should match against the upstream security tracker directly.

Hardening that pays off independently of CVEs

In rough priority:

  1. Bind to localhost or a private interface only. bind_ip in MongoDB, bind in Redis, listen_addresses in PostgreSQL, bind-address in MySQL. The single most impactful database security control.
  2. Enable authentication and use strong passwords. Even on private networks — internal lateral-movement is a real threat. MongoDB --auth, Redis requirepass, MySQL/PostgreSQL drop the anonymous accounts at install time.
  3. Run with minimum-privilege accounts. The application connects with an account that has access to its own schema and nothing else. Backups run from a different account. Replication runs from a third.
  4. Encrypted connections. TLS between application and database is no longer expensive; both PostgreSQL and MySQL handle it natively. For MongoDB: --tlsMode requireTLS.
  5. Don’t put backup files in the web root. A surprising number of data leaks come from database.sql.gz being downloadable from https://example.com/backup/database.sql.gz.

How blueredix surfaces database findings

Database services are detected on standard ports (3306 MySQL, 5432 PostgreSQL, 27017 MongoDB, 6379 Redis, 1433 MSSQL) plus version fingerprinting from the protocol handshake. Findings show:

  • Open-port info by itself, prominently flagged when a production database is visible from outside your network — even before any CVE match.
  • CVEs against the running version, with applicability filtering to drop the false positives wildcard CPE matching produces for older databases.

Tightening the network exposure is almost always the higher-priority action versus chasing the CVE list.

Further reading