Elasticsearch Security and the Open Database Problem: MongoDB and Redis Leaks in 2026

By Mohana SubiPublished 03-11-2026Updated 04-11-2026

One research team tracked exposed databases for years. Of the MongoDB instances it found answering on the default port without a password, nearly every one already held a ransom note. Elasticsearch was not far behind. For these engines, an open port is no longer a risk you might face. It is an incident that has probably already happened.

Short answer: Elasticsearch security, like MongoDB and Redis security, fails at the network edge. An exposed database is an engine that accepts connections from the public internet without authentication, or that runs a flaw that lets an attacker skip authentication. Automated scanners find these servers within hours. Most are then copied, wiped, ransomed or hijacked.

This post sets out what the 2026 data shows, how each engine gets attacked, why secure defaults have not fixed the problem, and how to check your own estate today.

Key Judgments

1. Treat an unauthenticated MongoDB, Elasticsearch or Kibana instance on a default port as already compromised. Confidence: high. Two independent 2026 studies found ransom notes on somewhere between half and nearly all of the open instances they examined.

2. Redis exposure has shifted from data theft toward host takeover. Confidence: medium to high. Redis botnets install miners, rootkits and ransomware. At least seven Redis flaws disclosed between October 2025 and May 2026 can lead to code execution, and three have public write-ups or working exploits. Each one can turn an open or weakly protected Redis from a data leak into a foothold on the host.

3. Your data can leak from an open database you do not own. Confidence: high. The largest exposure of 2026 was a compilation of stolen credentials, left open on Elasticsearch by an operator the researchers did not identify. Vendors, data brokers and criminals all run these engines badly.

4. Authentication alone is no longer enough. Confidence: medium to high. MongoBleed showed that a pre-authentication memory leak can pull secrets out of a password-protected MongoDB. Network exposure is the control that matters most.

What Is an Exposed Database, and Why Does Elasticsearch Security Keep Failing?

An exposed database is a data store whose service port answers requests from anyone on the internet. The common ones and their default ports:

Engine	Default port	What one unauthenticated request can return
Elasticsearch	9200 (REST API over HTTP)	Every index name, then every document. A browser is enough.
Kibana	5601	A full search and admin interface over the Elasticsearch cluster behind it
MongoDB	27017	A list of databases, then every collection
Redis	6379	Every key, plus commands that can rewrite server configuration

All three engines were built for trusted networks. Their vendors have spent a decade adding guardrails. Elastic made authentication, authorization and network encryption switch on automatically from the first start of Elasticsearch 8.0, which shipped in 2022. MongoDB has bound to localhost by default since version 3.6. Redis has shipped with "protected mode" since 3.2.

The guardrails have not ended the leaks. In March 2026, researchers reported an open cluster holding more than 676 million US identity records. A version with security on by default was serving data to anyone. Someone switched security off, or exposed the cluster in a way that bypassed it. That pattern, a safe default undone during deployment, runs through almost every case in this post.

How Big Is the Open Database Problem in 2026?

Exposure figures vary by an order of magnitude depending on what is being counted. Before quoting any of them, check which population it describes.

Measure	Figure	Source	What it counts
MongoDB servers publicly discoverable	200,000+	Flare, Feb 2026	Port answers; many still require a login
MongoDB servers open with no access restriction	3,100	Flare, Feb 2026	No authentication at all
MongoDB instances potentially vulnerable to MongoBleed	87,000+	Censys, Dec 2025	Reachable and in the affected version range
Redis instances exposed to the internet	About 330,000	Wiz, Oct 2025	Port reachable
Redis instances with no authentication	About 60,000	Wiz, Oct 2025	No password set
Exposed databases carrying a ransom or wipe note	30,515 of 65,907	Ransomnews, May 2021 to May 2026	Multi-engine, five-year tracking

A February 2026 study found more than 200,000 publicly discoverable MongoDB servers. Of these, 3,100 had no access restriction, and 1,416 of those (45.6%) had already been wiped and replaced with a ransom note. The Ransomnews study found a far higher rate for direct, unauthenticated exposure. Of 3,532 MongoDB instances it found on a default port, 3,525 carried a ransom note. Elasticsearch was 6,055 of 6,185, and Kibana 3,739 of 3,821.

Analyst note on the gap between 45.6% and 99.8%. The two studies measured different things. The February study took a single snapshot of everything open at one moment, including servers exposed that morning. Ransomnews tracked systems over five years, so it caught most of them after scanners had already visited. Read together, the floor is roughly half and the ceiling is almost all. Neither number supports the idea that an open database might go unnoticed.

The trend is still upward. Ransomnews saw only 31 ransom-marked databases in 2021, a sixteen-fold rise by 2023, and a 2026 count that passed the full 2025 total by mid-May.

What Happens to an Open Database After Scanners Find It?

The attack chain is short and almost fully automated. A script scans default ports across the IPv4 space, connects, reads or copies what it can, and then acts. What it does next depends on the engine.

Stage	Elasticsearch and Kibana	MongoDB	Redis	MITRE ATT&CK
Discovery	Mass scan of 9200 and 5601	Mass scan of 27017	Mass scan of 6379	T1595 Active Scanning
Access	Unauthenticated REST calls	Unauthenticated connection, or MongoBleed memory read	Unauthenticated commands, or post-login code execution flaws	T1190 Exploit Public-Facing Application
Collection	Dump indices	Dump collections	Dump keys, session tokens	T1213 Data from Information Repositories
Persistence	Rare	Rare	Cron job or SSH key written via CONFIG SET; rogue module via replication	T1053.003 Cron, T1098.004 SSH Authorized Keys
Defense evasion	Rare	Rare	Disable protected mode; user-mode rootkit	T1562.001 Impair Defenses, T1014 Rootkit
Impact	Delete indices, leave note	Drop databases, leave note	Cryptomining, ransomware on host	T1485 Data Destruction, T1496 Resource Hijacking

The key difference: Elasticsearch and MongoDB attacks end at the data. Redis attacks often end at the operating system, because Redis commands can write files to disk.

Elasticsearch: The Leak Engine

Elasticsearch produces the largest single exposures on record, because it is where organisations put big, searchable piles of records.

June 2026, 24 billion credential records. Cybernews found an open Elasticsearch cluster holding about 24 billion records with plaintext passwords, pulled from 36 sources. More than 30 of those sources were Telegram channels, and most of the material traced back to infostealer logs. The owner was still adding to it. Researchers found the cluster on June 12, 2026, and it was closed by June 15. One detail matters for defenders. A subset of about 17,000 records included more than 9,500 documents that paired CVE IDs with GitHub repository links. That looks like targeting data. A plain dump would not need it.

Reported February 2026, 8.7 billion Chinese records. The cluster held 163 indices on bulletproof hosting and stayed open for about three weeks in January 2026. Researchers warned the data may already have been scraped.

March 2026, 676 million US identity records. Social Security numbers and dates of birth sat in one index on a current Elasticsearch version. Unlike a password, neither can be changed.

India. The pattern is not new here. In 2018 an open Elasticsearch and Kibana deployment leaked live location data for more than 11,000 buses run by 27 Indian government transport agencies. The researcher reported it to CERT-In on November 30, 2018, and the servers were secured by December 22. In August 2020, RailYatri left 43 GB of customer and corporate data on an open Elasticsearch server. The Meow bot wiped most of it two days after researchers found it, and the database was locked only after the researchers went to CERT-In.

Analyst note. The largest cluster of 2026 is a fourth-party problem. Your staff's stolen passwords can sit in an open database run by a criminal or a breach-monitoring service you have never heard of. You cannot fix that server. You can find out what it held about you and rotate those credentials.

MongoDB: The Ransom Engine

MongoDB is where database extortion became a business. In January 2017, at least 15 groups hijacked more than 27,000 MongoDB databases within days, wiping data and leaving notes asking for bitcoin. Nine years later the method is the same and the operators are fewer.

The economics. Ransomnews extracted 514 attacker wallets from ransom notes. Of the 512 it could trace, 318 never received a payment, and total confirmed revenue across the dataset was 9.78 BTC, roughly $753,000. Most of that went to a handful of operators. One wallet appeared in 1,283 notes across 1,234 victim IP addresses in 49 countries, always asking for exactly 0.01 BTC, from October 2023 through May 2026.

Why destruction gave way to extortion. The 2020 Meow bot wiped databases and asked for nothing. Ransomnews found only 53 Meow notes in its whole dataset and concluded that the purely destructive approach died because it earned nothing. Profit-driven scripts survived. One note family now threatens to report victims to EU regulators for exposing customer data, which turns the victim's compliance exposure into a pressure point.

Paying does not help. The report's central finding is that the damage is the same whether or not the victim pays. In most cases the attacker copied the data, deleted it, or both, before the note appeared. Your backups are your recovery plan, not the wallet address.

MongoBleed, December 2025.This was the first serious pre-authentication flaw in years. MongoDB disclosed CVE-2025-14847 on December 19, 2025, a flaw in the server’s zlib-based network compression. It lets an unauthenticated attacker read leftover heap memory, which can hold credentials, keys and query data. Some early reports called it remote code execution, but it is a pre-authentication information disclosure flaw. It was serious enough anyway. The flaw affects server versions 3.6 through 8.2.2, and CISA added it to its Known Exploited Vulnerabilities catalog with a federal remediation deadline of January 19, 2026. On one day, 74,854 of 78,725 publicly reachable MongoDB instances were flagged as potentially vulnerable, with India among the top countries.

Analyst note. MongoBleed breaks the "we set a password, so we are fine" argument. A password-protected MongoDB on the internet could still leak the secrets in its memory. If you ran an exposed, unpatched MongoDB in late December 2025, rotate the credentials and keys that process handled, even after patching.

Redis: The Takeover Engine

Redis is usually deployed as a cache, so teams treat it as low value. That is a mistake on two counts. Caches hold session tokens and API keys. Redis commands can also change where the server writes files, which turns database access into host access.

Botnets. Researchers found the HeadCrab malware on at least 1,200 Redis servers. It uses the SLAVEOF command to make each victim a replica of an attacker-controlled instance, syncs a malicious module across, then loads it. In June 2024, researchers reported that the P2PInfect worm, which abuses the same replication trick, had added ransomware and a cryptominer. The Migo campaign switches off Redis protections, plants a cron job that fetches its payload, runs a modified XMRig miner, persists through a systemd service and timer, and hides with a user-mode rootkit.

RediShell, October 2025. Researchers disclosed CVE-2025-49844, known as RediShell, a use-after-free bug reachable through crafted Lua scripts. It can escape the sandbox and run code on the host. The vulnerable code dates to 2012. It is rated CVSS 10. It needs an authenticated session, but the researchers counted about 330,000 internet-exposed Redis instances, around 60,000 with no authentication. They also noted that the official Redis container image has authentication off by default. At disclosure there was no evidence of exploitation in the wild.

CVE-2025-62507, November 2025. A stack overflow in the XACKDEL command affects Redis 8.2.0 and later and was fixed in 8.2.3. JFrog researchers published a working code execution exploit in January 2026.

CVE-2026-23479, May 2026. This use-after-free was demonstrated at ZeroDay.Cloud in December 2025. Redis disclosed and patched it on May 5, 2026, together with four companion CVEs, in 7.2.14, 7.4.9, 8.2.6, 8.4.3 and 8.6.3. It needs a login, but the default user already holds the privileges it requires. A public write-up of the full exploit chain followed in June. Criminal IP counted about 16,090 internet-facing assets in the potentially affected range as of June 2026.

Analyst note. Every one of these flaws needs a login. On 60,000 internet-facing instances with no password, that requirement does not exist. On the rest, a shared application password stored in a config file or a leaked .env is often enough.

Why Didn't Secure Defaults End This?

The defaults improved. The way teams deploy databases did not. These root causes recur in public incident reports:

Security switched off on purpose. A developer disables authentication to get a client library working and never turns it back on. The 676 million record cluster fits this pattern.
Container images with open defaults. The official Redis image ships with no password and protected mode turned off. A single -p 6379:6379 publishes it to anyone who can reach the host.
Docker and host firewalls. Docker writes its own iptables rules for published ports, and on many Linux hosts those rules take effect before UFW sees the traffic. The team believes the firewall blocks the port. It does not.
Cloud security groups opened "for a minute". An inbound rule from 0.0.0.0/0 added during debugging outlives the debugging session.
Migrations and clones. A cluster stood up to move or test data rarely gets the hardening production got, and it often outlives the job. Staging copies of production data get less care than production.
Vendors and contractors. Agencies, analytics vendors and outsourced developers stand up clusters in their own cloud accounts with your data inside. Your cloud security tooling never sees those accounts.

The fix has moved from the database to the pipeline. The question is no longer "is the default safe?" but "what in our build, deploy and vendor process can expose a port without anyone noticing?"

Who Pays When a Database Is Left Open?

The organisation pays in lost data, recovery time, incident response and regulatory exposure. An extortion note in production also forces a breach investigation, because you have to assume the data was copied before it was deleted.

The public pays more, and for longer. Identity numbers and dates of birth cannot be reissued. Infostealer logs carry session cookies that let attackers skip multi-factor authentication. Customers whose records sat in an open cluster face years of targeted phishing and account takeover attempts, usually without ever learning which company exposed them.

The regulator's clock starts once you know. In India, the CERT-In Directions of April 2022 require reporting cyber incidents, data leaks included, within six hours of noticing them. The DPDP Rules add a two-stage breach notice to the Data Protection Board: an intimation without delay on a best-knowledge basis, then a detailed report within 72 hours. The Rules were notified on 13 November 2025, and the breach provisions take effect 18 months later, in May 2027. Unlike GDPR, they set no risk threshold, so every personal data breach is reportable. Banks and market entities also face RBI and SEBI timelines, typically around six hours.

Jurisdiction	Main clock
India	CERT-In: 6 hours. DPDP Rule 7: initial notice without delay, detail within 72 hours
EU	GDPR: 72 hours to the supervisory authority. NIS2: 24-hour early warning for in-scope entities
Australia	APRA CPS 234: 72 hours for material incidents at regulated entities
United States	SEC: 4 business days after a public company determines an incident is material; state breach laws vary

This table is a summary, not legal advice. Check obligations with counsel for your sector.

Timeline: Open Database Incidents, 2017 to 2026

Date	Event	Engine
Jan 2017	At least 15 groups wipe and ransom more than 27,000 databases within days	MongoDB
Nov 2018	Live location data for 11,000+ buses run by 27 Indian government transport agencies exposed	Elasticsearch, Kibana
2020	Meow bot wipes thousands of open databases, including RailYatri	Elasticsearch, MongoDB
Sept 2021 onward	HeadCrab botnet grows to 1,200+ servers for Monero mining	Redis
2024	Migo disables Redis protections and hides with a rootkit (Feb). P2PInfect adds ransomware and a miner (Jun)	Redis
Oct 2023 to May 2026	Single wallet campaign asks 0.01 BTC from 1,234 victim IPs	Multi-engine
Oct to Nov 2025	RediShell, CVE-2025-49844, CVSS 10.0. XACKDEL overflow, CVE-2025-62507	Redis
Dec 2025	MongoBleed, CVE-2025-14847, added to CISA KEV on Dec 29	MongoDB
Jan 2026	8.7 billion Chinese records left open for about three weeks (reported in February)	Elasticsearch
Feb 2026	Flare: 1,416 of 3,100 open servers found wiped	MongoDB
Mar 2026	676 million US identity records exposed	Elasticsearch
May 2026	Redis patches CVE-2026-23479 and four companions. Ransomnews five-year study published	Redis, multi-engine
Jun 2026	24 billion credential records found open, closed three days later	Elasticsearch

Technical Details and Hunting Indicators

Use these on systems you own to check for past compromise.

Elasticsearch and Kibana

An index named in the style of a ransom note (for example containing "read_me") with all other indices gone
DELETE requests against /* or _all in audit or proxy logs
High-volume _search or _cat/indices calls from IPs outside your clients

MongoDB

A database named READ_ME_TO_RECOVER_YOUR_DATA or similar, holding a README collection
dropDatabase operations from unfamiliar sources
Ransom notes referencing wallet bc1qe2l4ffmsqfdu43d7n76hp2ksmhclt5g9krx3du (published by Flare as a wallet in its 2026 sample)
For MongoBleed: bursts of short pre-authentication connections using zlib-compressed messages from one source

Redis

INFO replication showing role:slave with an unknown master_host (SLAVEOF or REPLICAOF abuse)
MODULE LIST showing a module you did not install
CONFIG GET dir pointing to /var/spool/cron, /etc/cron.d or a .ssh directory
protected-mode set to no at runtime
Unknown custom commands (HeadCrab registers eight commands prefixed rds, such as rdsa and rdss)
Files such as /tmp/.migo or /tmp/.migo_worker, an unexpected system-kernel.service with a timer, a new /etc/ld.so.preload entry, unexpected cron entries, XMRig processes, or /etc/hosts entries that blackhole East Asian cloud provider domains (all reported for Migo)

How Do You Fix Elasticsearch Security, MongoDB and Redis Exposure?

Start with one rule: no database engine port should answer from the public internet. Applications reach databases over private networks. Analysts reach them through a VPN, bastion or SSO proxy. Everything below is defence in depth on top of that rule.

Elasticsearch and Kibana

Keep xpack.security.enabled: true. Treat any config that sets it to false as a build failure.
Bind network.host to a private interface only.
Put Kibana behind SSO or a VPN. Never publish 5601.
Remove any role that grants anonymous access.
Take snapshots to a repository the cluster's own credentials cannot delete.

MongoDB

Enable security.authorization and bind net.bindIp to private addresses.
Upgrade to a release with the MongoBleed fix: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 or 4.4.30, or later. The 4.2 line and older need a major upgrade.
If you cannot upgrade, remove zlib from networkMessageCompressors.
If an exposed instance ran an affected version, rotate the secrets it handled.
Enforce TLS for client connections.

Redis

Keep protected-mode yes and bind to private interfaces.
Use ACL users with least privilege. No single application user should hold @admin and @scripting together.
Block CONFIG, SLAVEOF, REPLICAOF, MODULE and DEBUG for application users.
Block EVAL and EVALSHA through ACLs if you do not use Lua scripting.
Run Redis as a non-root user.
Upgrade to the May 2026 releases (7.2.14, 7.4.9, 8.2.6, 8.4.3, 8.6.3 or later), which also carry the October and November 2025 fixes. On the 6.2 line, move to 6.2.22.

Across all three

Publish Docker ports to 127.0.0.1 only, for example -p 127.0.0.1:6379:6379.
Add a CI policy check that fails any infrastructure change opening 9200, 5601, 27017 or 6379 to 0.0.0.0/0.
Keep offline or immutable backups.
Check your external footprint continuously, including vendor-hosted systems, because a port that was closed last week can open in tomorrow's deploy.

A fair note on tooling. Cloud security posture tools do this well inside the cloud accounts you know about. Internet search engines such as Shodan and Censys are good for spot checks of known IP ranges. Where both fall short is the asset nobody listed: the contractor's cluster, the acquired company's staging server, the developer's personal cloud account holding a production copy. External attack surface monitoring exists to find those, because attackers start from the internet, not from your asset register. Our guide to EASM best practices for 2026 covers how to build that discovery process.

Key Takeaways

An unauthenticated MongoDB, Elasticsearch or Kibana instance on a default port should be handled as an incident, not a finding.
Redis exposure now leads to host takeover through botnets and recent code execution flaws.
Secure defaults exist in all three engines. Exposures come from deployment shortcuts, containers, firewall gaps, migrations and vendors.
Paying a database ransom rarely changes the outcome. Backups and closing the exposure do.
Your credentials can leak from open databases you do not own, so monitoring has to extend past your own estate.

Am I Exposed?

Run these from a network outside your own, and only against systems you own or are authorised to test.

☐ Elasticsearch: Does curl -s http://<your-host>:9200/ return cluster details without asking for credentials? Does anything answer on 5601?
☐ MongoDB: Does mongosh "mongodb://<your-host>:27017" --eval "db.adminCommand({listDatabases:1})" succeed without a username? Is any internet-reachable instance below 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 or 4.4.30?
☐ Redis: Does redis-cli -h <your-host> -p 6379 PING return PONG without AUTH? Is any instance older than the May 2026 patch releases?
☐ Containers: Does any docker run or Compose file publish 6379, 27017 or 9200 without binding to 127.0.0.1?
☐ Vendors: Do you know where your agencies and analytics vendors host copies of your customer data, and whether those clusters are reachable?

If you cannot answer the last two with confidence, the first three only cover part of your exposure.

What Scrutex Finds Here

Scrutex maps the subdomains and IP addresses tied to your domains and flags any that answer on database ports such as 9200, 5601, 27017 and 6379 from the internet. It reads the version a service advertises and checks it against known CVEs and active exploitation, so an exposed, unpatched MongoDB ranks above an exposed, patched one. It flags employee and customer credentials for your domains that appear in stealer logs and leak compilations. It runs the same external checks on vendors you add.

Scrutex sees what the internet sees. It does not log in to your databases or read their contents, and it will not find a Redis instance that is reachable only from inside your network. If a database sits on a bare cloud IP with no DNS record and no other link to your domains, external discovery can miss it.

What That Looks Like

Illustrative finding format. Sample data, not a customer.

Is Anything on Your Domain Answering on 9200, 27017 or 6379?

Find out whether any host on your domains has Elasticsearch, MongoDB or Redis open to the public internet. Start with just your domain on the Scrutex free tier. No credit card, no agent.

Check your domain for open databases

Where to Go Next

If the open port is on your own assets: Vulnerability Insights, which covers open ports, exposed services and outdated database versions across your discovered footprint.
If the database belongs to an agency or processor holding your data: Vendor Insights, which runs the same external checks on the third parties you add.
Going deeper on discovery: EASM best practices for 2026, for building a process that catches shadow databases before scanners do.
If a compilation like the June 2026 cluster may hold your staff's passwords: How to find leaked credentials on the dark web.

FAQ

Q: Is Elasticsearch secure by default? A: Since version 8.0, Elasticsearch enables authentication and TLS automatically on first start. Exposures still happen because teams disable security during setup, run older 7.x clusters, or put Kibana on the internet. A secure default only helps if nobody turns it off.

Q: How quickly do attackers find an exposed database? A: Usually within hours. Automated scanners sweep default ports across the internet continuously. Five-year tracking by Ransomnews found ransom notes on about 98% to 99.8% of directly exposed MongoDB, Elasticsearch and Kibana instances.

Q: Should I pay a MongoDB or Elasticsearch ransom note? A: Research shows the damage is the same whether victims pay or not, and most attacker wallets never receive a payment. In most cases the data was already copied or deleted. Restore from backups, close the exposure and treat the event as a possible breach.

Q: Does setting a Redis password fix the risk? A: It removes the easiest attack, but it is not enough. RediShell and CVE-2026-23479 both work after login, and shared application passwords leak often. Keep Redis off the internet, use least-privilege ACLs, block CONFIG and replication commands for application users, and patch.

Q: Do I have to report an exposed database in India? A: If the database held personal data, CERT-In expects a report within six hours of you noticing the leak. The DPDP Rules add notice to the Data Protection Board and to affected individuals once the breach provisions take effect in May 2027. Confirm the specifics for your sector with legal counsel.