WordPress Vulnerability Database API
路
Up-to-date One of the initial objectives of the WPVulnerability project has been to have as much information available in the most reliable way possible. And although we are constantly working on improving many aspects, today we can announce a new milestone in this process: we have finished incorporating all WPScan vulnerabilities. Presently, we have processed,
路
Unfixed, revisited When a plugin or theme is marked as unfixed, the vulnerability is enabled, but, if fixed, there was no easy way to report it. This is why, starting today, we are going to retest unfixed vulnerabilities occasionally to analyze if they are fixed and update the API information. In the coming days we
路
Wordfence vulnerabilities As we announced 3 weeks ago, we’ve added, review, and checked over 9,500 new vulnerabilities and added hundreds of new plugins and themes to the API. This has helped to expand the information and improve thousands of existing data. Unify duplications We are going to work in some internal projects, the main one
路
Closed plugins From now on, plugins that are closed, or are going to close, in the WordPress.org repository, will automatically cause all vulnerabilities in that plugin to mark that the plugin is closed. In the same way, those plugins with vulnerabilities marked as closed, but that the plugin has been reopened, will be properly maintained.
路
Fix (v1.5.1) There was an incongruencies between the “updated” data in the “last updated” API and the “public” API. This value should be the date (unixtime) when, in the database, the information is updated. In the “latest updated” API, the value was correct, but not in the “public” API, where the value was the time
路
Plugins API The Plugins API includes, from today, a new field called “latest” that informs, in UNIXTIME, the date of last update of a plugin. It is not available in all plugins (it will be available progressively) and its value can be unixtime or null. “latest”: “1664858712” As a general rule, a plugin is considered