According to a study from the Ransomnews Research Team, researchers tracking exposed databases over the past five years found 2,931 MySQL instances reachable from the open internet. 2,930 of them carried ransom or wipe notes. That is not a sample of the unlucky. It is effectively the entire population. Exposing a MySQL server to the internet in 2026 is, statistically, a guarantee of compromise.

The study, published in June 2026, catalogued 65,907 exposed systems across MongoDB, MySQL, Elasticsearch, Kibana, and HTTP admin panels between May 2021 and May 2026. 30,515 of them (46.3%) carried ransom or wipe notes, spanning more than 215 billion records. The attackers behind them collected a confirmed 9.78 BTC (around $753,000) across 514 traceable wallets. The mechanism that produced these numbers is not new, not sophisticated, and not patched. It is the same approach a campaign called PLEASE_READ_ME used in 2020.

The 2020 Playbook That Never Stopped Working

Guardicore Labs captured the first attack from a campaign it named PLEASE_READ_ME on January 24, 2020, and documented it in full that December. The method was almost crude in its simplicity: scan the internet for MySQL servers listening on port 3306, brute-force weak passwords, then run SQL queries to copy the database out, delete the original, and leave a ransom note. The campaign installed a persistent backdoor user, mysqlbackups’@’%’, to retain access even after a password reset.

By the time Guardicore published, PLEASE_READ_ME had breached 83,000 victims and listed 250,000 databases for sale, totalling roughly 7 terabytes of stolen data. The operation later evolved from direct Bitcoin wallets to a Tor leak site with double extortion, publishing stolen databases to pressure victims who did not pay.

Six years later, the technique requires no revision. No exploit, no CVE, no zero-day. As Chris Wallis, CEO of attack-surface firm Intruder, put it, these exposures “don’t even need a CVE to be exploited. For example, an exposed database or admin panel can be compromised through brute force or credential stuffing alone.”

One in Four Organizations Still Leaves MySQL Open

The reason the playbook still works is that the underlying mistake is still common. Intruder’s 2026 Attack Surface Management Index, released in May 2026, found that one in four organizations has an exposed MySQL database reachable from the internet. 16% expose PostgreSQL, 8%expose phpMyAdmin, and nearly half have some form of risky exposed port or service.

Exposure alone would be survivable if it were brief. It is not. Intruder found that midmarket organizations take an average of 56 days to close a known security gap. An exposed database does not need 56 days to be found. It needs seconds.

Your Database Is the New SSH

The speed of attack is not a recent discovery. As far back as 2021, Palo Alto Networks Unit 42 deployed a set of honeypots with deliberately weak credentials and watched a single threat actor compromise 96% of the PostgreSQL instances, every one of them within 30 seconds of coming online. The exposure window between provisioning a weakly secured database and its first compromise is measured in seconds, not days.

What has changed since then is the volume. Global honeypot sensors logged more than 218 million malicious events in January 2026, with attacks on MSSQL more than doubling from 53 million to 113 million in a single month as threat actors pivoted away from RDP toward database ports. By May 2026, one sensor network recorded 179 million attack events. Security researchers have started describing the database port as “the new SSH” – the default target for automated, internet-wide brute-force scanning that once focused on remote login services.

The File Nobody Watches: llms.txt Is the Hosting Industry’s Newest Attack Surface

Why Hosting Environments Are Especially Exposed

The pattern matters more for hosting providers, agencies, and VPS operators than for most. A self-managed VPS ships with no firewall opinions. A developer who installs MySQL or PostgreSQL for an application, binds it to 0.0.0.0 instead of localhost, and sets a weak root password has created exactly the target these campaigns scan for. The database is reachable on port 3306 or 5432, the credentials are guessable, and no application-layer vulnerability is required.

This is the failure mode that does not show up in a vulnerability scanner looking for CVEs. The software is fully patched. The configuration is the hole. For a hosting company running thousands of customer VPS instances, the exposure is multiplied across every tenant who provisioned a database without locking it down, and the provider often carries the reputational damage when those tenants are breached.

The Defenses Have Not Changed Either

The countermeasures are as old as the attack and just as unglamorous. They work, and the numbers above exist because they are not applied. Four of them prevent the breach; the last one limits the damage when prevention fails.

  • Do not expose the database to the internet. Bind MySQL and PostgreSQL to localhost or a private network interface. If remote access is genuinely needed, put it behind a VPN or an SSH tunnel, not a public port.
  • Firewall ports 3306 and 5432. Default-deny inbound, allow only known application hosts. Most exposed databases are exposed by omission, not intent.
  • Enforce strong credentials and drop default accounts. Brute force and credential stuffing are the entire attack. Strong passwords and disabled default admin accounts break it.
  • Audit for unexpected users. PLEASE_READ_ME left mysqlbackups’@’%’ behind. A periodic check for unfamiliar database users catches persistence that survives a password change.
  • Back up offline. Double extortion assumes the victim has no recourse. Tested, offline backups remove the leverage of deletion, though not of publication.

Six years separate PLEASE_READ_ME from the 2026 figures, and the gap between them is filled with the same unforced error repeated at scale. The databases are not being broken into. They are being left open.