top of page
Search

How I got my first CVE: CVE-2025-4222

  • Writer: Guy .
    Guy .
  • 18 hours ago
  • 6 min read

CVE-2025-4222 - Wordpress Plugin Vulnerability Research


Plugin: Database Toolset

Version: 1.8.4

Active Installations: 800+

Downloads: 25,043

Last Updated: April 19, 2025

Security Researcher: Guy Shavit


Background

When I first stepped into the cybersecurity field, CVEs felt like the ultimate milestone — a point of recognition that only a select few get to achieve. After completing my OSCP, I set my sights on finding my first 0day. It wasn’t just about getting a CVE for the sake of it, but about understanding how vulnerabilities come to life, how they’re discovered, and how they can be responsibly disclosed.

This post is a reflection of that journey and a contribution back to the community. Whether you're looking to learn more about web vulnerabilities, or perhaps even taking your first steps toward finding your own CVE, I hope this helps you in your research.


What is a CVE

A CVE (Common Vulnerabilities and Exposures) is a publicly disclosed cybersecurity vulnerability that affects a specific software or system. Each CVE is assigned a unique identifier, making it easier for security researchers, developers, and organizations to communicate about, track, and patch vulnerabilities. A CVE itself doesn't describe the details of the vulnerability — that's typically found in its associated advisory or report — but it serves as a reference point for further investigation.

For security researchers, CVEs represent not only the risk a vulnerability poses but also the validation of their work in identifying and responsibly reporting flaws. Getting a CVE assigned to a discovery is one of the highest honors in cybersecurity, but it’s also a responsibility to ensure that users are protected and aware of the risks.


What is a CNA?

A CNA (CVE Numbering Authority) is an organization authorized to assign CVE (Common Vulnerabilities and Exposures) identifiers to vulnerabilities. CNAs play a critical role in the vulnerability management ecosystem by reviewing and verifying vulnerability reports, assigning CVEs, and ensuring proper disclosure. CNAs are recognized entities that contribute to the CVE list, providing standardized identifiers for vulnerabilities, which help the cybersecurity community track and address security issues.


Approach

I’ve watched an enormous amount of videos and read countless blogs about CVEs—what they are, how to find them, how to report them, and what exactly a CNA is. I have almost three years of experience as a security researcher, with certifications including OSCP, CRTP, OSWP, and PORP, so I’m not a beginner in the field. After going through all of this material, consulting with many friends who have already earned their own CVEs, I chose to focus on WordPress plugin security. I saw this as a great way to learn and potentially find my first 0-day.

At first, it felt like searching for a needle in a haystack, but then I discovered Wordfence and learned that they are an official CNA (Certificate Authority) and can grant CVEs. I began using their WordPress plugin database and started going through plugin after plugin, looking for ones that already had CVEs. This approach seemed promising, as plugins with existing CVEs are often more vulnerable (though not always). I aimed for plugins with moderate download numbers—not too many, but enough to have a meaningful impact on the cybersecurity landscape.

That's when I found the Database Toolset plugin, and everything changed.


Who are WordFence?

Wordfence is a leading WordPress security company that provides a comprehensive security solution for WordPress websites. They specialize in threat detection and prevention, including malware scanning, firewall protection, and performance optimization. Wordfence is an official CNA (Certificate Authority) and offers a bug bounty program for WordPress plugins and themes. While my finding wasn't eligible for a bounty, it was indeed eligible for a CVE. They were the CNA to whom I reported my vulnerability.


What is the Database Toolset Plugin?

The Database Toolset plugin is a WordPress plugin designed to facilitate database management for WordPress users. It provides a set of tools that allow admins to manage and interact with their website’s database, including creating backups and exporting data. The plugin helps users with tasks like database optimization, table management, and data export. While it offers useful functionalities, its security flaws can have serious consequences if left unaddressed, as seen with the vulnerability I discovered.


What is a CWE? And What is CWE-200?

A CWE (Common Weakness Enumeration) is a classification system used to categorize software weaknesses. It's often referenced when discussing vulnerabilities and helps provide a common language for identifying and discussing specific types of flaws. CWE-200, specifically, refers to the Exposure of Sensitive Information to an Unauthorized Actor.

In the case of CVE-2025-4222, the vulnerability falls under this category because it exposes database backups, which contain sensitive user information such as passwords and personal data, to anyone who can find the URL. This flaw could lead to a complete breach of confidentiality and compromise of the WordPress installation.


How I reported the Vulnerability

After identifying the vulnerability in the Database Toolset plugin, I carefully documented the issue, ensuring that I had sufficient evidence of the problem. I then reported it to Wordfence, leveraging their status as an official CNA. Wordfence reviewed the vulnerability and, after validation, assigned it a CVE number, officially acknowledging the issue and allowing for proper disclosure. While my finding wasn’t eligible for a bug bounty, it was a rewarding step in my journey to contribute to the cybersecurity community and earn my first CVE.


Technical Dive:

Vulnerability: Unauthenticated Access to Database Backup Files

The plugin stores full SQL database backups in a publicly accessible directory under:

`/wp-content/uploads/export/database/`

The backups are saved with filenames in the following format:

`backup-<db_name>-<timestamp>-<random>.sql`

Example:

`backup-wordpress_db-20250419173559-12345678.sql`

There is no authentication or access control on this path.

Any unauthenticated user can download these files directly if the filename is known.


Example of an attacker unauthenticated (Going to the endpoint directly from Incognito Mode):


An attacker, during an attack, can go to the endpoint and download the entire database of the victim's website, giving the attacker the entire database of the WordPress instance of the organization.



Including the WordPress admin username and password hash, all the tables inside the database including sensitive information.


Example of sensitive content inside the SQL file:

The contents of the SQL Backup File
The contents of the SQL Backup File

This kind of attack can lead to sensitive information disclosure, having huge impact on confidentiality, and even by breaking the admin user password hash, to an entire website takeover.


Testing The Plugin Backup Logic

The Wordpress site admin can set up a scheduled task (cronjob) that will make a backup dump of the entire SQL database every chosen time:



After setting up the task, at the "Backups" page, the admin can view his backups, remove a backup and also download it.



Using BurpSuite, Capturing the request to the sql dump endpoint to check the "Download" button, the file endpoint is:

Request in BurpSuite
Request in BurpSuite

`/wp-content/uploads/export/database/backup-wordpress_db-20250419173559-12345678.sql`

Security Design Flaw

Sensitive database dumps are stored in a static, predictable, and web-accessible location with no authentication.


This is a broken access control issue.

- The backup URL is not precise, but not protected.

- Exposure is possible by design, regardless of randomness.

- Accessing a direct URL should never be enough to retrieve sensitive data.


This violates secure design principles and creates a critical information disclosure vector.


Although the file name includes some randomness (timestamp + 8-digit random number), the critical security flaw is the storage location itself — in a public, unauthenticated, web-accessible folder (/wp-content/uploads/export/database/).


Why this is exploitable:

URLs are high-risk attack vectors:

- URLs are logged in load balancers, reverse proxies, browser history, logs, cache systems, and even analytics tools.

- Once a backup file’s URL is accessed even once, it can be leaked or recovered later by:

- A user who previously had access but shouldn't anymore.

- A third-party cache/CDN/log aggregator.

- Shared browser history or phishing.

- Unlike sessions or headers, URLs can be copied, stored, or misused easily and persist outside the app’s control.


So even if the file name was truly random — which it’s not — the design flaw is that secrets are stored in an exposed directory without any authentication check or short-lived signed access.


Impact

- Full exposure of WordPress database contents

- Disclosure of password hashes, emails, plugin configurations, etc.

- Potential for admin account takeover via password cracking

- Critical confidentiality breach


CVSS v3.1 Vector

```
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Score: 5.9 (Medium)
```

CWE Mapping

- CWE-200: Exposure of Sensitive Information to an Unauthorized Actor


Recommendation

- Store backups outside the web root.

- Apply access control to all sensitive resources.

- Avoid exposing file names via predictable logic or email.

- Use secure, token-authenticated download links.


References

bottom of page