Skip to content
HACKTECH
Data exposureReported Published 2 sources

Flare: 1,416 of 3,100 fully exposed MongoDB servers found wiped with ransom notes

Cybersecurity company Flare reported on 26 January 2026 that its analysis found more than 200,000 publicly discoverable servers running MongoDB, of which slightly over 100,000 disclosed operational information and 3,100 were fully exposed without access restrictions. Of those 3,100, Flare said 1,416 (45.6%) had already been compromised, with their databases wiped and replaced by a ransom note; in nearly all cases the demand was approximately $500 in Bitcoin. BleepingComputer reported the findings on 1 February 2026, quoting Flare's warning that 'there is no guarantee the attackers have the data, or will provide a working decryption key if paid.'

  • MongoDB
  • exposed databases
  • ransom demands
  • Shodan
  • Docker
  • CVE-2025-14847

What the sources report

  • Flare combined Shodan scans with a honeypot deployed across several geolocations, searches of Docker Hub and GitHub for MongoDB configurations and exposed credentials, dark web intelligence and penetration testing.
  • Over a three-month window Flare identified 763 Docker Hub container images whose start command runs mongod with --bind_ip=0.0.0.0; two widely used projects with over 15,000 pulls each included the same setup.
  • Only five distinct Bitcoin wallets were observed across all incidents, one appearing in over 98% of cases; Flare estimated attacker earnings at between $0 and $842,000.
  • A little more than 95,000 servers (46.3%) had at least one vulnerability, mostly limited to denial-of-service impact; Flare said the late-2025 disclosure of MongoBleed (CVE-2025-14847) reinforced that MongoDB remains a high-value target.
  • Flare's recommendations include not exposing MongoDB directly to the internet, blocking port 27017 from public ingress, enabling authentication and role-based access, and avoiding default Docker images and copy-paste configurations that bind MongoDB to 0.0.0.0.

What it means for your organisation

One wallet appeared in over 98% of cases, which Flare says points to a single dominant actor, and it describes bots scanning for vulnerable instances, so an exposed MongoDB server should be assumed found. Flare found 763 Docker Hub images whose start command binds mongod to 0.0.0.0 and warns against copy-paste configurations that do the same; since paying gives no assurance of recovery, a tested restore from backup decides the outcome.

What we check

  • Scan external IP ranges and cloud security groups for MongoDB (27017) and other database ports reachable from the internet.
  • Confirm authentication and role-based access control are enforced on every instance, including development, test and container-based deployments.
  • Review Dockerfiles, Helm charts and compose files for 0.0.0.0 bind addresses and for database credentials committed to repositories or baked into images.
  • Verify that offline or immutable backups exist and that restores have been tested, and look for unexpected databases or collections containing ransom notes.
  • Check MongoDB versions against known vulnerabilities, including CVE-2025-14847.

Sources

Services that cover these checks

  • Database security audit

    A configuration and access review of your production databases: who can connect, from where and with which privileges, whether data is encrypted at rest and in transit, what is logged, and whether backups would survive the same attacker. We read each instance's live configuration.

    Duration: 3 to 7 working days

  • Network & infrastructure testing

    Internal and external network testing, including Active Directory. Where scope allows we go from an unauthenticated foothold to domain-wide impact and document the whole chain: the exposed service or sprayed credential that got us in, each privilege escalation on the way, and the accounts and hosts it reached.

    Duration: 5 to 12 working days

  • Cloud configuration review

    An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.

    Duration: 4 to 8 working days

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works