MongoDB and Elasticsearch: patching and stopping data-ransom attacks

Updated November 2026

MongoDB and Elasticsearch servers left open to the internet are a favorite target of data-ransom bots. They find the port, read or delete everything, and leave a note demanding payment. Patching matters, but the first fix is network access and authentication. Then keep each product on the latest patch release of a supported series.

9.0.4MongoDB 9.0 release that fixed the October 13, 2026 CVEs
9.5.5 / 9.4.8 / 8.19.23Elasticsearch security fixes, October 6, 2026
27017 / 9200Default ports to keep off the internet

How the ransom attacks work

The attack is automated. A firewall rule or an enabled login stops it at step 1 or 2.

No exploit is needed when the server accepts connections from anywhere without a password. You cannot check whether the attackers kept a copy, so restore from your own backups and treat the data as leaked. See ransomware response and data breach.

MongoDB: check the version

mongod --version
mongosh --quiet --eval 'db.version()'       # running server (add credentials if needed)
apt policy mongodb-org-server               # Debian, Ubuntu
rpm -q mongodb-org-server                   # RHEL family, SUSE

MongoDB: supported versions

MongoDB supports each major version for five years. When a new minor release comes out, the previous minor stops getting patches. From 9.0, self-managed servers get only the major releases and a yearly Feature Update release numbered x.5.

MongoDB Server lifecycle, as of November 2026
Version	Released	End of life
9.0	September 2026	October 31, 2031
8.3	May 2026	October 31, 2029
8.0	October 2024	October 31, 2029
7.0	August 2023	August 31, 2027
8.2	September 2025	Ended July 31, 2026
6.0	July 2022	Ended July 31, 2025
5.0 and older	—	Ended

MongoDB's security alerts of October 13, 2026 were fixed in 9.0.4, 8.3.13, 8.0.34 and 7.0.45. In December 2025, CVE-2025-14847 (CVSS 8.7) showed why network exposure matters. A length mismatch in zlib-compressed protocol headers could let a client read uninitialized server memory. It affected every release line from 3.6 to 8.2, and the end-of-life lines 4.2 and older got no fix.

MongoDB: update and restart

Install the official mongodb-org packages from repo.mongodb.org. The mongodb package in Debian and Ubuntu is not maintained by MongoDB Inc. and conflicts with the official one. The repository path names one series (for example mongodb-org/9.0), so updates stay within that series. MongoDB 9.0 packages exist for RHEL 8–10, Ubuntu 22.04, 24.04 and 26.04, Debian 13, and SLES 15 and 16. On FreeBSD, use the mongodb80 or mongodb70 package.

# Debian, Ubuntu
sudo apt-get update
sudo apt-get install -y mongodb-org

# RHEL family
sudo dnf upgrade --refresh 'mongodb-org*'

# SUSE
sudo zypper refresh
sudo zypper update mongodb-org

# FreeBSD (as root)
pkg upgrade mongodb80

# Docker: same series tag, then recreate
docker pull mongo:9.0
docker compose up -d

If you pinned versions (apt-mark hold or an exclude= line in the dnf configuration), lift the pin for the update. The restart stops the database briefly: sudo systemctl restart mongod (FreeBSD: service mongod restart). In a replica set, do a rolling restart. Upgrade the secondaries one at a time, then step down the primary with rs.stepDown() and upgrade it last.

Major upgrades go one major at a time. 7.0 must go to 8.0 before 9.0. Before a major upgrade, set the feature compatibility version (FCV) to the current release. Raise it only after a burn-in period, because raising it is the point after which you can no longer downgrade:

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
db.adminCommand( { setFeatureCompatibilityVersion: "9.0", confirm: true } )   // after the upgrade, when ready

MongoDB: lock it down

mongod binds to localhost by default, and the official packages set bindIp: 127.0.0.1. Access control, however, is off by default (security.authorization defaults to disabled). So if anyone widens bindIp, the data is open to everyone who can reach the port. Check:

sudo ss -tlnp | grep -E ':27017\b'
grep -A3 -E '^(net|security):' /etc/mongod.conf
mongosh --quiet --eval 'db.adminCommand({ listDatabases: 1 })'   # should fail without login

To turn on authentication, create a user administrator first. If you turn on access control before creating any user, the localhost exception lets you create the first one from the server itself. Then set this in /etc/mongod.conf and restart:

security:
  authorization: enabled

Write enabled in lower case. Versions before 9.0.0, 8.3.9, 8.2.13, 8.0.30 and 7.0.41 silently ignored values such as Enabled and left authorization off. Newer versions refuse to start with them. Also bind only to a private interface if other hosts must connect, use TLS, run as a dedicated OS user, and start with --noscripting if you don't use server-side JavaScript.

Elasticsearch: check the version

curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic https://localhost:9200
dpkg -l elasticsearch            # Debian, Ubuntu
rpm -q elasticsearch             # RHEL family, SUSE

The JSON reply includes "number" under "version". If plain http:// without a password works, security is switched off: fix that first.

Elasticsearch: supported versions

Elastic maintains a major release for 30 months from release, or until 18 months after the next major release, whichever is later. Within that period, only the two newest minors of the current major and the last minor of the previous major get fixes. Support runs six months past the end of maintenance.

Elasticsearch maintenance, as of November 2026
Series	Maintained minors	End of maintenance	End of support
9.x	9.5, 9.4	October 15, 2027 or later (depends on the 10.0 release date)	Six months later
8.x	8.19	January 15, 2027	July 15, 2027
7.17	—	April 15, 2025	Ended January 15, 2026

On October 6, 2026, Elastic published advisories ESA-2026-195 to 199, fixed in 8.19.23, 9.4.8 and 9.5.5. They cover an authorization bypass in cross-cluster search, a privilege escalation and several denial-of-service bugs. Elastic's install pages list 9.5.6 as the latest release.

Elasticsearch: update and restart

Elastic's repositories contain one major series each (packages/9.x or 8.x). The RPM repository file sets enabled=0, so you have to enable it for each command. Elastic publishes .deb, .rpm, archive and Docker builds. The FreeBSD port (textproc/elasticsearch8) was still at 8.11.3 in November 2026, well outside maintenance.

# Debian, Ubuntu
sudo apt-get update
sudo apt-get install --only-upgrade elasticsearch

# RHEL family
sudo dnf upgrade --enablerepo=elasticsearch elasticsearch

# Docker
docker pull docker.elastic.co/elasticsearch/elasticsearch:9.5.5

Package updates do not restart Elasticsearch (RESTART_ON_UPGRADE defaults to false), so the old version keeps running until you restart each node. For a cluster, do a rolling restart. Upgrade data nodes first (frozen, cold, warm, then hot), then other nodes, and master-eligible nodes last. For each node:

ES="curl -s --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic"
$ES -X PUT https://localhost:9200/_cluster/settings -H 'Content-Type: application/json' \
  -d '{"persistent":{"cluster.routing.allocation.enable":"primaries"}}'
sudo systemctl stop elasticsearch.service        # stops this node
# upgrade the package and any plugins (elasticsearch-plugin), then:
sudo systemctl start elasticsearch.service
$ES -X PUT https://localhost:9200/_cluster/settings -H 'Content-Type: application/json' \
  -d '{"persistent":{"cluster.routing.allocation.enable":null}}'
$ES 'https://localhost:9200/_cluster/health?wait_for_status=green&timeout=10m'

Wait for green before you move to the next node. Upgrade Kibana and other Elastic Stack parts to matching versions.

Elasticsearch: lock it down

Since 8.0, Elasticsearch turns security on by default: it generates TLS certificates and requires a login. Clusters first built on 7.x or older may still run without it. Note one detail. On first start, the package's security auto-configuration binds the HTTP layer to 0.0.0.0, so port 9200 is reachable from the network, protected only by the password. Unless remote clients need it, set http.host to 127.0.0.1 or a private address in /etc/elasticsearch/elasticsearch.yml, and firewall 9200 and 9300. Check with sudo ss -tlnp | grep -E ':(9200|9300)\b'. Reset the elastic password with /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic, and give applications their own users with minimal roles.

Where advisories appear

MongoDB security alerts, with an RSS feed for CVE alerts.
Elastic security announcements, with an RSS feed. Report Elastic issues to security@elastic.co.
Our vulnerability pages.

Quick hardening tips

Never expose 27017, 9200 or 9300 to the internet. Bind to localhost or a private address and firewall the ports. See firewall basics.
In Docker, publish as 127.0.0.1:27017:27017, or don't publish at all and use an internal network.
Turn on authentication (MongoDB authorization: enabled; Elasticsearch security), and test from outside that anonymous access fails.
Give each application its own user with least privilege. Never use the elastic superuser or a MongoDB root user in application code.
Use TLS between nodes and for any client that is not on the same host.
Keep versioned, off-server backups (mongodump or filesystem snapshots, Elasticsearch snapshots) and test restores. See backups.
Upgrade before end of life: MongoDB 7.0 ends August 31, 2027, and Elasticsearch 8.x maintenance ends January 15, 2027.