What the WordPress vulnerability database does today
We have launched a searchable catalogue of reported WordPress security issues. You can search by plugin name, theme name or CVE ID (a public reference number given to many reported flaws), then narrow the results by category and severity. Each advisory lists the affected versions, whether a fix is available, remediation advice, source references and licence notices.
The reports currently come from Wordfence Intelligence, and every entry links back to its original source. Our role at this stage is to bring those records together in a form a site owner can read quickly, without first working out where to look. When we announced the launch on X, we described the database as the start of a longer project rather than a finished one, and the rest of this post explains why.
Checking your own site against the catalogue
The database becomes useful once you compare its records with what is installed on your site. A plugin name alone settles nothing, because a report applies only to the versions it lists. Work through the check in order:
When you already know a plugin's slug and installed version, our free plugin vulnerability lookup offers a quicker route. You enter those two details, it compares that release with the available records and highlights the most severe matching advisory with a link to its source. The lookup does not connect to your website, so the result is only as accurate as the slug and version you type in.
- Note your versions. Plugins > Installed Plugins shows each plugin version, Appearance > Themes and then Theme Details shows the theme version, and Dashboard > Updates shows your WordPress version.
- Search the catalogue by plugin or theme name, or paste a CVE ID if you already have one.
- Compare your installed version with the affected range in the advisory, and open the original report linked from the entry.
- Back up the site, test the update on a staging copy if you have one, then install the version that contains the fix.
- When no fix is listed, ask your developer or support team whether to disable or replace the affected plugin or theme.
Reading a result without overreading it
A listed vulnerability describes a flaw in a piece of software. On its own, an entry is no evidence that anyone has used that flaw against your website, so a match calls for an update and a closer look rather than panic.
An empty search needs the same care in the other direction. No results means we hold no matching published report. The database does not scan your installation, inspect your files or look for signs of a break-in, so a clean search is no confirmation of safety.
Updating also has a limit worth stating plainly. Installing the fixed version moves you out of the affected range named in the advisory, which is the right outcome. A smooth update still proves nothing about what happened before it. Unfamiliar administrator accounts, changed files or odd redirects belong to a separate investigation, and the update alone does not answer them.
Why published reports and source code play different roles
Every entry in a vulnerability catalogue describes a flaw someone has already found, examined and published. Those reports are valuable because they come with affected versions and fixes, and they give owners something concrete to act on. They are also, by nature, a record of the past: the flaw existed in the code before anyone wrote it up.
Source-code research starts earlier in that chain. Instead of waiting for a report, it analyses WordPress plugins and examines their source code for potential security flaws. Catalogue data tells you what has been confirmed. Code research aims to surface questions worth investigating. One cannot replace the other, which is why we want both under the same roof.
The AI-assisted research we are building
We are developing an AI-assisted process that examines WordPress plugin source code and flags potential security flaws. Our aims are earlier detection and broader coverage, so that owners and developers learn about risks sooner and across more plugins than published feeds alone reach.
The work remains in development, and we are not claiming any new discoveries from it. A potential flaw flagged in source code is an unverified lead: it needs verification before anyone can treat it as a confirmed vulnerability.
Where the WordPress vulnerability database fits in your routine
The official WordPress security guidance puts one action above the rest: keep WordPress, plugins and themes up to date, and prefer plugins and themes that still receive updates. The same guidance points out that risk never reaches zero, which is why recovery planning matters as much as prevention.
Our catalogue supports that routine rather than replacing it. Use it to decide which updates deserve attention first and to read the original research behind a warning. Keep regular backups so a bad update or a compromise has a way back. Then update everything, including software with no listed issues, because a missing report is simply a missing report.
Sources
WordPress vulnerability database FAQs
Does the BugShield vulnerability database scan my website?
No. The database is a searchable catalogue of published reports. It does not connect to your site, inspect files or check for signs of a break-in. You compare your installed versions with the affected versions in each advisory.
Where do the vulnerability reports come from?
The catalogue currently uses reports from Wordfence Intelligence. Each entry links to its original source and lists affected versions, fix availability and remediation advice.
Has BugShield's AI research found new WordPress vulnerabilities?
We are not claiming any new discoveries. The AI-assisted source-code research is in development, and a potential finding from it needs verification before it can be treated as a confirmed vulnerability.
Does a listed vulnerability mean my site has been hacked?
No. A listing describes a flaw in certain versions of a plugin, theme or core. Check whether your installed version falls in the affected range, update to the fixed version, and investigate separately if you see unfamiliar users or changed files.
What should I do if an advisory shows no fix?
Read the original report for any interim advice, then ask your developer or support team whether to disable or replace the affected plugin or theme. Back up the site before making that change.