Researchers Just Scanned the Open Internet and Found 555,000 Exposed Database Ports. 501,000 of Them Are Redis With Zero Authentication.
A ZoomEye-based internet scan collected on September 18 and published a day later found roughly 555,000 database ports sitting open on the public internet. Of those, 501,664 were Redis instances on the default port, 6379. Another 27,971 were MySQL on port 3306, and 26,089 were PostgreSQL on port 5432. Read that ratio again: Redis alone accounts for about 90% of everything found, and there's a specific, boring reason why.
Redis doesn't require a password by default. You install it, you run it, it listens, and unless you went out of your way to set requirepass or bind it to a private interface, it will answer to anyone who finds the port. MySQL and PostgreSQL both ship with authentication enabled out of the box, which is why they show up in this scan by the tens of thousands instead of the hundreds of thousands, they're still exposed as login surfaces vulnerable to brute force and credential stuffing, but at least there's a lock on the door.
Why this isn't a story about big companies
Stories about exposed databases usually get written when a specific company gets breached and a security researcher writes up the postmortem. This one's different: it's a scan of the entire reachable internet, not one incident, and the population it's describing is mostly not enterprise infrastructure with a security team that should have caught this. Big companies run their Redis behind VPCs and load balancers as standard practice, because they have an infrastructure team whose job is to notice this kind of thing.
Half a million exposed instances is closer to the sum of every quick side project, every "let me just spin up Redis for this weekend hackathon idea," every abandoned staging environment from a product that got 40% built and then shelved. I've done exactly this. I'd guess most people reading this have too: spun up a database on a cloud box to test something, got it working, moved on to the next problem, and never circled back to lock down the network config because the thing worked and there was always something more urgent.
What actually happens if you're on this list
An exposed Redis instance with no auth isn't just a theoretical risk, it's a practical one that gets found fast, because scans like the one behind this article aren't rare, and they're not the only ones running. Once an unauthenticated Redis instance is found, an attacker can read and write everything in it, which for a lot of setups means session tokens, cached user data, or job queue contents. Redis also has a well-known history of being used as a foothold for further compromise on the host it's running on, not just a place to steal data from directly.
MySQL and PostgreSQL exposure is a different risk profile: default auth means the attacker needs valid credentials, so the practical danger is weak or reused passwords getting brute-forced, or credentials that leaked somewhere else (a .env file committed to a public repo, a leaked CI log) getting tried against every exposed instance a scanner can find, including yours.
The check, right now
This takes less time to run than it took to read the section above it.
# From a machine OUTSIDE your own network, check if the port answers at all nc -zv your-server-ip 6379 nc -zv your-server-ip 3306 nc -zv your-server-ip 5432
If any of those connect from outside your own infrastructure, that port is reachable from the internet. For Redis specifically, also check whether auth is actually required:
redis-cli -h your-server-ip ping
If that returns PONG without you supplying a password, you have an open Redis instance right now, full stop.
The fix, in order of how much it costs you
First, and cheapest: bind the database to a private network interface or localhost instead of 0.0.0.0, so it's simply not reachable from outside your own infrastructure. This is a one-line config change for Redis, MySQL, or Postgres, and it's the single highest-value fix on this list.
Second: set a real password. For Redis specifically, requirepass in redis.conf, or better, Redis 6+'s ACL system if you need more than one credential. This should be true even for instances you've already firewalled, because network configs get changed by future-you at 11pm without remembering why the old rule was there.
Third, if you're on a managed provider (RDS, Supabase, Upstash, Redis Cloud, and similar): use the provider's network isolation features (VPC peering, IP allowlists, private endpoints) instead of exposing the instance's public endpoint directly and relying on a password alone as your only layer of defense.
The honest take
I don't think the lesson here is "always use a managed provider" as a blanket rule, plenty of solo devs run their own databases successfully and cheaply, and self-hosting isn't inherently reckless. The lesson is narrower: whatever you're running, know whether it's reachable from the open internet, and don't let "it worked when I tested it" stand in for "I checked the network config." Those are different facts, and it's easy to only ever verify the first one.
Where this could be overstated: not every exposed instance in that 555,000 is a live, valuable target. A lot of them are probably empty test databases, abandoned projects nobody's touched in a year, or honeypots. But you don't get to assume yours is the empty one without checking, and the check costs you two minutes.
What I'd actually do
Run the nc and redis-cli ping checks above against every database you have running right now, today, not on your someday list. If you find one that answers, fix the network binding first, the password second. Then set a recurring reminder, monthly is enough, to re-run the same check, because the config that's locked down today can drift the next time you or a deploy script touches it.
Author
Lukas
@lukcombinator