WPVulnerability
| 开发者 |
closetechnology
davidperez javiercasares lbonomo alexclassroom robotstxt |
|---|---|
| 更新时间 | 2026年8月23日 15:02 |
| PHP版本: | 7.0 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPL-3.0-or-later |
| 版权网址: | 版权信息 |
标签
下载
4.3.0
2.0.3
4.0.3
1.1
1.3.2
2.0.2
2.0.4
1.0.1
1.2.0
1.3.3
2.0.0
2.0.1
0.1
1.2.2
2.2.1
3.0.1
2.2.0
3.0.2
3.1.0
4.0.0
3.1.2
3.2.0
1.2.4
3.0.0
3.1.1
3.2.2
3.3.0
1.0
3.3.1
3.3.2
4.0.1
4.0.4
4.1.0
4.1.1
4.2.0
4.2.1
1.2.1
1.3.0
1.3.1
3.4.0
4.2.1.1
3.3.4
4.3.1
4.3.2
2.1.0
1.2.3
3.3.5
3.4.1
5.0.0
0.2
3.3.3
4.0.2
5.0.1
5.1.1
5.1.2
5.1.6
详情介绍:
This plugin integrates with the WPVulnerability API to provide real-time vulnerability assessments for your WordPress core, plugins, themes, PHP version, Apache HTTPD, nginx, MariaDB, MySQL, ImageMagick, curl, memcached, Redis, and SQLite.
It delivers detailed reports directly within your WordPress dashboard, helping you stay aware of potential security risks. Configure the plugin to send periodic notifications about your site's security status, ensuring you remain informed without being overwhelmed. Designed for ease of use, it supports proactive security measures without storing or retrieving any personal data from your site.
Data reliability
The information provided by the information database comes from different sources that have been reviewed by third parties. There is no liability of any kind for the information. Act at your own risk.
安装:
Automatic download
Visit the plugin section in your WordPress, search for [wpvulnerability]; download and install the plugin.
Manual download
Extract the contents of the ZIP and upload the contents to the
/wp-content/plugins/wpvulnerability/ directory. Once uploaded, it will appear in your plugin list.屏幕截图:
常见问题:
Where does the vulnerability information come from?
The origin is in the WPVulnerability.com API. The vulnerabilities that appear in this API come from different sources, such as CVEs.
Is data from my site sent anywhere?
No. Never. Your privacy is very important to us. We do not commercialize with your data.
What vulnerabilities will I find?
Vulnerabilities in WordPress Core, Plugins, Themes, PHP, Apache HTTPD, nginx, MariaDB, MySQL, ImageMagick, curl, memcached, Redis, and SQLite are documented.
What do I do if my site has a vulnerability?
First of all, peace of mind. Investigate what the vulnerability is and, above all, check that you have the latest version of the compromised element. We actively recommend that you keep all your WordPress and its plugins up to date. Contact your hosting provider to patch non-WordPress vulnerabilities (like web server, databases, and other software).
更新日志:
[5.1.6] - 2026-08-22
Fixed
- Saving the "Delete all plugin data on uninstall" preference no longer triggers a fatal error (
add_settings_error()was called before the WordPress admin API was loaded). - Notification channels can now be disabled entirely: unchecking every channel and saving previously kept the old channels active, because unchecked checkboxes are never submitted.
- "Reset Plugin" and "Delete all logs" now purge both log stores (API request logs and shell execution audit logs). Previously the shell audit store was never cleaned, and both deletions silently did nothing because the log post types were not registered yet when the actions ran.
- The Debug tab API connectivity tests now use the real API routes: WordPress core collapses pre-release versions (e.g. 7.1-alpha) to their stable milestone, and plugins/themes are tested against their actual slug routes instead of nonexistent plural ones (HTTP 404).
- Component icons now carry explicit width/height attributes and a meaningful alt text. The same icons are embedded in notification emails and Site Health, where the plugin CSS is not loaded and unsized SVGs rendered at their intrinsic 800x800 size.
languages/wpvulnerability.potregenerated with the new strings.
- WordPress: 4.7 - 7.1
- PHP: 7.0 - 8.5
- WP-CLI: 2.3.0 - 2.12.0
- PHP Coding Standards: 3.13.6 (0 errors)
- WordPress Coding Standards: 3.4.1
- PHPStan: 2.2.9 (level 9, 0 errors)
- PHPUnit: 9.6.36 (54 tests)
- The contributor list now leads with the ROBOTSTXT organization account, followed by Javier Casares; the remaining contributors are unchanged.
- Regenerated
languages/wpvulnerability.potso its source references match the current code. The string set is unchanged (450 strings); all shipped translations were verified against it and remain fully up to date.
- WordPress: 4.7 - 7.1
- PHP: 7.0 - 8.5
- WP-CLI: 2.3.0 - 2.12.0
- PHP Coding Standards: 3.13.6
- WordPress Coding Standards: 3.4.1
- PHPStan: 2.2.9 (level 9, 0 errors)
- PHPUnit: 9.6.36 (45 tests)
- The Site Health vulnerability tests work again on every WordPress version: they were silently disabled everywhere by an availability gate that could never pass. Secrets are now masked in the admin forms, and compatibility was verified against real PHP interpreters from 5.6 to 8.5.
- The Site Health integration registered its tests behind
class_exists( 'WP_Site_Health' ), but core loads that class lazily, afterinit, where the plugin loads its modules — so the guard always evaluated to false and none of the 13 vulnerability tests ever appeared in Site Health. The filter is now registered unconditionally; below WordPress 5.2 it simply never fires. - "Clear all caches" in the debug tools now also deletes the
wpvulnerability-plugins-cache-datatimestamp option, so the plugins dataset is fully refreshed afterwards. - The notification email "From:" address is now sanitized with
sanitize_email()on all code paths. - The plugins list table "Last updated" column decoded the whole plugins dataset for every table row; it is now decoded once per request.
- Removed a duplicated
json_decode()call when reading the vulnerable-themes count. - The
wp_date()compatibility polyfill no longer fatals on WordPress 4.7–5.3: core callswp_maybe_decline_date()unconditionally, but that function only exists since 5.4; the call is now availability-guarded. - The core and software JSON getters return
'[]'instead of an empty string when encoding fails, matching the plugins and themes getters.
- Webhook URLs (Slack, Teams, Discord) and the Telegram bot token are masked in the admin settings forms (single-site and network), showing only their last 4 characters — previously they were rendered in full into the page HTML. The inputs are plain text fields, so masked values never trigger browser URL validation. Saving a form with unchanged masked values keeps the stored secret; clearing a field still removes it.
- Removed the dead
register_uninstall_hook()registration:uninstall.phpsupersedes it and the registration added a stray autoloaded option row. - Single-site settings registrations now explicitly set
show_in_rest => false, matching the multisite configuration.
- Admin CSS/JS assets load only on the WPVulnerability settings pages, the dashboard and the plugins/themes list tables instead of on every wp-admin screen.
- The shell availability probe (
wpvulnerability_can_shell_exec()) result is cached per request instead of spawning a process on every call.
- WordPress: 4.7 - 7.1
- PHP: 7.0 - 8.5
- WP-CLI: 2.3.0 - 2.12.0
- Verified against real PHP interpreters 5.6.40, 7.0.33, 7.1.33, 7.2.34, 7.3.33, 7.4.33, 8.0.30, 8.1.34, 8.2.33, 8.3.33, 8.4.24 and 8.5.9: every plugin file lints clean from 7.0 up and fails on 5.6, confirming the declared floor. PHPCompatibility gate 7.0-8.5 clean; wp-compat WordPress floor 4.7 clean.
- PHP Coding Standards: 3.13.6
- WordPress Coding Standards: 3.4.1
- PHPStan: 2.2.9 (level 9, 0 errors)
- PHPUnit: 9.6.36 (45 tests)