CVE-2026-101148: A CVSS 10 WordPress Backup Plugin That Never Got a Fix

The National Vulnerability Database published CVE-2026-101148 with a CVSS score of 10.0, the maximum. The flaw is in BackupSheep, a WordPress backup plugin, through version 1.8. It does not validate its integration key. An unset or blank key is treated as valid. That means an unauthenticated attacker can create and download a full site backup, database included, password hashes and all, and delete arbitrary files on the server.

The part that should stop you cold is the second half of the advisory. BackupSheep has been closed on WordPress.org since July 2024. There is no fixed version. The vendor is not shipping one. The only remediation the NVD offers is removal.

A CVSS 10 with no patch is not a rare shape in the WordPress ecosystem. It is a recurring one, and it is worth being precise about why, because the same conditions now sit under a surprising amount of AI infrastructure.

The mechanism is embarrassingly simple

There is no memory corruption here, no race condition, no clever type confusion. The plugin checks an integration key, and the check fails open. A blank string passes. From there the attacker reaches the backup functionality, which by design exports the whole database.

Password hashes are the prize. WordPress stores them with phpass, a portable hashing framework that is deliberately weak by modern standards and, critically, salted per-user but not stretched the way bcrypt or Argon2 are. A dumped wp_users table is a cracking job, not a research project. Crack the admin hash, log in, and the site is yours. The arbitrary file deletion is the second act: pull wp-config.php, or wipe the uploads directory, or use the deletion primitive to clear a security plugin’s own files before you move.

None of this requires the attacker to know anything about the target beyond a URL. That is what a 10.0 means. No privileges, no user interaction, no special conditions. The advisory does not list a CWE, which is itself a small tell: the flaw is a logic error, an authorization check that returns the wrong answer, and those are under-represented in the taxonomy relative to how often they cause breaches.

The AI angle is not the plugin. It is the pattern.

BackupSheep is not an AI tool. So why does it matter to anyone building with models?

Because the AI stack is now a WordPress stack wearing a different hat. Look at what a modern AI product actually depends on. A retrieval pipeline pulling from a CMS. A marketing site and a docs site, both WordPress, both with a backup plugin, both with a contact-form plugin, both with a page builder that bundles its own dependency tree. An internal wiki. A customer portal. The model is the interesting part; everything around it is ordinary web software, and ordinary web software is where the CVSS 10s live.

The specific failure mode here, an abandoned plugin with no patch path, is the same failure mode that shows up in AI tooling constantly. A vector database client library whose maintainer stopped responding. A tokenizer wrapper pinned to a version with a known parsing bug. A GPU monitoring agent that shells out to a helper binary nobody has audited since 2023. The difference is that WordPress at least has a mechanism for this: the plugin directory closes listings, and the NVD writes it down.

The AI ecosystem has no equivalent registry. There is no WordPress.org for the long tail of Python packages, Node modules, and Rust crates that a typical inference service pulls in. PyPI will yank a package for malware, but it does not maintain a “closed, unpatched, remove it” list the way WordPress.org does. So when an AI-adjacent dependency goes unmaintained with a live vulnerability, the signal is weaker and the discovery is slower.

What “no fixed version” actually costs

The advisory’s remediation is one sentence: remove it from any site where it is installed. That is easy to write and hard to execute.

Consider what a backup plugin is for. It is the thing you install so you can recover when something else goes wrong. Removing it removes your recovery path, or forces a migration to a different plugin, which means re-establishing backup schedules, re-testing restore procedures, and re-verifying that the new tool actually captures the database. That is a real operational cost, and it lands on exactly the operators least equipped to absorb it: the solo maintainer running a small site, the researcher hosting a lab wiki, the two-person team running a model demo behind a WordPress front end.

The alternative is worse. An unauthenticated, no-interaction, full-database-exfiltration bug on a public endpoint is not a “monitor and see” situation. It is a “you are already compromised or you are about to be” situation. The gap between disclosure and exploitation for bugs like this is measured in hours, not weeks, because the exploit is a single crafted HTTP request. There is no skill barrier.

The uncomfortable read

Here is the take. The WordPress plugin ecosystem is a preview of what happens to AI tooling as it ages. Plugins get abandoned. Maintainers move on. A directory listing gets closed, and the code keeps running on millions of sites anyway, because removal is a manual act that someone has to remember to perform.

For AI builders specifically, the lesson is not “audit your WordPress plugins,” though you should. It is that your dependency surface is larger than the part you think of as your product, and the abandoned corner of it is where the 10.0s hide. The model weights get all the attention. The backup plugin gets none, until it gets a CVE.

What to watch: whether WordPress.org’s closure mechanism, which is the closest thing this ecosystem has to a coordinated removal signal, gets adopted anywhere in the AI tooling world. Right now it has not been. The next CVSS 10 with no patch will probably not be a backup plugin, and it probably will not have a directory listing to close.