| 1 |
=== WPVulnerability === |
| 2 |
Contributors: javiercasares, davidperez, lbonomo, alexclassroom |
| 3 |
Tags: security, vulnerability, site-health |
| 4 |
Requires at least: 5.6 |
| 5 |
Tested up to: 7.1 |
| 6 |
Stable tag: 5.1.2 |
| 7 |
Requires PHP: 7.0 |
| 8 |
Version: 5.1.2 |
| 9 |
License: GPL-3.0-or-later |
| 10 |
License URI: https://spdx.org/licenses/GPL-3.0-or-later.html |
| 11 |
|
| 12 |
Get WordPress vulnerability alerts from the [WPVulnerability Database API](https://www.wpvulnerability.com/). |
| 13 |
|
| 14 |
== Description == |
| 15 |
|
| 16 |
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. |
| 17 |
|
| 18 |
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. |
| 19 |
|
| 20 |
= Data reliability = |
| 21 |
|
| 22 |
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. |
| 23 |
|
| 24 |
== Using the plugin == |
| 25 |
|
| 26 |
= WP-CLI = |
| 27 |
|
| 28 |
You can use the following WP-CLI commands to manage and check vulnerabilities: |
| 29 |
|
| 30 |
* Core: `wp wpvulnerability core` |
| 31 |
* Plugins: `wp wpvulnerability plugins` |
| 32 |
* Themes: `wp wpvulnerability themes` |
| 33 |
* PHP: `wp wpvulnerability php` |
| 34 |
* Apache HTTPD: `wp wpvulnerability apache` |
| 35 |
* nginx: `wp wpvulnerability nginx` |
| 36 |
* MariaDB: `wp wpvulnerability mariadb` |
| 37 |
* MySQL: `wp wpvulnerability mysql` |
| 38 |
* ImageMagick: `wp wpvulnerability imagemagick` |
| 39 |
* curl: `wp wpvulnerability curl` |
| 40 |
* memcached: `wp wpvulnerability memcached` |
| 41 |
* Redis: `wp wpvulnerability redis` |
| 42 |
* SQLite: `wp wpvulnerability sqlite` |
| 43 |
|
| 44 |
To configure the plugin you can use: |
| 45 |
|
| 46 |
* Hide component: `wp wpvulnerability config hide <component> [on|off]` |
| 47 |
* Notification email: `wp wpvulnerability config email <emails>` (comma separatted) |
| 48 |
* Notification period: `wp wpvulnerability config period <never|daily|weekly>` |
| 49 |
* Log retention: `wp wpvulnerability config log-retention <0|1|7|14|28>` (in days) |
| 50 |
* Cache duration: `wp wpvulnerability config cache <1|6|12|24>` (in hours) |
| 51 |
|
| 52 |
All commands support the `--format` option to specify the output format: |
| 53 |
|
| 54 |
* `--format=table`: Displays the results in a table format (default). |
| 55 |
* `--format=json`: Displays the results in JSON format. |
| 56 |
|
| 57 |
Need help? |
| 58 |
|
| 59 |
* `wp wpvulnerability --help`: Displays help information for WPVulnerability commands. |
| 60 |
* `wp wpvulnerability [command] --help`: Displays help information for a WPVulnerability command. |
| 61 |
|
| 62 |
= REST API = |
| 63 |
|
| 64 |
The WPVulnerability plugin provides several **REST API endpoints** to fetch vulnerability information for different components of your WordPress site. |
| 65 |
|
| 66 |
* Core: `/wpvulnerability/v1/core` |
| 67 |
* Plugins: `/wpvulnerability/v1/plugins` |
| 68 |
* Themes: `/wpvulnerability/v1/themes` |
| 69 |
* PHP: `/wpvulnerability/v1/php` |
| 70 |
* Apache HTTPD: `/wpvulnerability/v1/apache` |
| 71 |
* nginx: `/wpvulnerability/v1/nginx` |
| 72 |
* MariaDB: `/wpvulnerability/v1/mariadb` |
| 73 |
* MySQL: `/wpvulnerability/v1/mysql` |
| 74 |
* ImageMagick: `/wpvulnerability/v1/imagemagick` |
| 75 |
* curl: `/wpvulnerability/v1/curl` |
| 76 |
* memcached: `/wpvulnerability/v1/memcached` |
| 77 |
* Redis: `/wpvulnerability/v1/redis` |
| 78 |
* SQLite: `/wpvulnerability/v1/sqlite` |
| 79 |
|
| 80 |
The WPVulnerability REST API uses **Application Passwords** for authentication. You need to include a valid Application Password in the Authorization header of your requests. |
| 81 |
|
| 82 |
Example Request with Authentication |
| 83 |
|
| 84 |
`curl -X GET https://example.com/wp-json/wpvulnerability/v1/plugins -u username:application_password` |
| 85 |
|
| 86 |
Replace username with your WordPress `username` and `application_password` with your [Application Password](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/). |
| 87 |
|
| 88 |
== Extra Configurations == |
| 89 |
|
| 90 |
= "From:" mail (since: 3.2.2) = |
| 91 |
|
| 92 |
If, for some reason, you need the emails sent by the plugin to have a From different from the site administrator, you can change it from the `wp-config.php` by adding a constant: |
| 93 |
|
| 94 |
`define( 'WPVULNERABILITY_MAIL', 'sender@example.com' );` |
| 95 |
|
| 96 |
If the constant is active, it will be visible in the configuration screen. |
| 97 |
|
| 98 |
= Force hiding checks (since: 4.1.0) = |
| 99 |
|
| 100 |
If you want to always hide a specific component, you can define a constant in `wp-config.php`. When set to `true`, the option will be checked automatically in the settings screen and the related analysis will be skipped. |
| 101 |
|
| 102 |
Example: |
| 103 |
|
| 104 |
`define( 'WPVULNERABILITY_HIDE_APACHE', true );` |
| 105 |
|
| 106 |
Available constants: `WPVULNERABILITY_HIDE_CORE`, `WPVULNERABILITY_HIDE_PLUGINS`, `WPVULNERABILITY_HIDE_THEMES`, `WPVULNERABILITY_HIDE_PHP`, `WPVULNERABILITY_HIDE_APACHE`, `WPVULNERABILITY_HIDE_NGINX`, `WPVULNERABILITY_HIDE_MARIADB`, `WPVULNERABILITY_HIDE_MYSQL`, `WPVULNERABILITY_HIDE_IMAGEMAGICK`, `WPVULNERABILITY_HIDE_CURL`, `WPVULNERABILITY_HIDE_MEMCACHED`, `WPVULNERABILITY_HIDE_REDIS`, `WPVULNERABILITY_HIDE_SQLITE`. |
| 107 |
|
| 108 |
= Cache duration (since: 4.1.0) = |
| 109 |
|
| 110 |
By default, data from the API is cached for 12 hours. To change this, define `WPVULNERABILITY_CACHE_HOURS` in `wp-config.php` with one of `1`, `6`, `12` or `24`. This value overrides the setting screen and WP-CLI command. |
| 111 |
|
| 112 |
`define( 'WPVULNERABILITY_CACHE_HOURS', 24 );` |
| 113 |
|
| 114 |
= Log rotation (since: 4.2.0) = |
| 115 |
|
| 116 |
WPVulnerability stores the most recent API responses so you can review recent calls from the new log tab. Define `WPVULNERABILITY_LOG_RETENTION_DAYS` in `wp-config.php` to control how many days of entries are preserved. Supported values are `0`, `1`, `7`, `14` or `28`; using `0` disables logging entirely. |
| 117 |
|
| 118 |
`define( 'WPVULNERABILITY_LOG_RETENTION_DAYS', 14 );` |
| 119 |
|
| 120 |
When the constant is present its value is enforced in the settings UI and through WP-CLI, ensuring consistent log rotation across environments. |
| 121 |
|
| 122 |
= Security configuration (since: 4.3.0) = |
| 123 |
|
| 124 |
WPVulnerability uses a hybrid detection approach for server software (ImageMagick, Redis, Memcached, SQLite): PHP extensions first (most secure), then shell commands as fallback (most accurate). You can control this behavior using security configuration constants in `wp-config.php`. |
| 125 |
|
| 126 |
**Global disable of shell commands:** |
| 127 |
|
| 128 |
`define( 'WPVULNERABILITY_DISABLE_SHELL_EXEC', true );` |
| 129 |
|
| 130 |
Completely disables shell command usage. Falls back to PHP extensions only. Use for maximum security when accuracy loss is acceptable. |
| 131 |
|
| 132 |
**Security mode (standard/strict/disabled):** |
| 133 |
|
| 134 |
`define( 'WPVULNERABILITY_SECURITY_MODE', 'strict' );` |
| 135 |
|
| 136 |
* `standard` - Hybrid detection: PHP extensions first, shell commands fallback (default, best accuracy) |
| 137 |
* `strict` - PHP extensions only, no shell commands (high security, lower accuracy) |
| 138 |
* `disabled` - No software detection at all (maximum security) |
| 139 |
|
| 140 |
**Component whitelist:** |
| 141 |
|
| 142 |
`define( 'WPVULNERABILITY_SHELL_EXEC_WHITELIST', 'imagemagick,redis' );` |
| 143 |
|
| 144 |
Allows shell commands only for specified components. Available components: `imagemagick`, `redis`, `memcached`, `sqlite`. Use for granular control. |
| 145 |
|
| 146 |
**Examples:** |
| 147 |
|
| 148 |
Maximum security (no shell commands): |
| 149 |
|
| 150 |
`define( 'WPVULNERABILITY_SECURITY_MODE', 'strict' );` |
| 151 |
|
| 152 |
Only allow ImageMagick shell detection: |
| 153 |
|
| 154 |
`define( 'WPVULNERABILITY_SHELL_EXEC_WHITELIST', 'imagemagick' );` |
| 155 |
|
| 156 |
Complete disable: |
| 157 |
|
| 158 |
`define( 'WPVULNERABILITY_DISABLE_SHELL_EXEC', true );` |
| 159 |
|
| 160 |
All shell commands are hardcoded and validated - no user input is involved. Commands are logged for security auditing. |
| 161 |
|
| 162 |
== Installation == |
| 163 |
|
| 164 |
= Automatic download = |
| 165 |
|
| 166 |
Visit the plugin section in your WordPress, search for [wpvulnerability]; download and install the plugin. |
| 167 |
|
| 168 |
= Manual download = |
| 169 |
|
| 170 |
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. |
| 171 |
|
| 172 |
== Frequently Asked Questions == |
| 173 |
|
| 174 |
= Where does the vulnerability information come from? = |
| 175 |
|
| 176 |
The origin is in the WPVulnerability.com API. The vulnerabilities that appear in this API come from different sources, such as CVEs. |
| 177 |
|
| 178 |
= Is data from my site sent anywhere? = |
| 179 |
|
| 180 |
No. Never. Your privacy is very important to us. We do not commercialize with your data. |
| 181 |
|
| 182 |
= What vulnerabilities will I find? = |
| 183 |
|
| 184 |
Vulnerabilities in WordPress Core, Plugins, Themes, PHP, Apache HTTPD, nginx, MariaDB, MySQL, ImageMagick, curl, memcached, Redis, and SQLite are documented. |
| 185 |
|
| 186 |
= What do I do if my site has a vulnerability? = |
| 187 |
|
| 188 |
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). |
| 189 |
|
| 190 |
== Screenshots == |
| 191 |
|
| 192 |
1. WP-Admin Dashboard widget. |
| 193 |
2. Vulnerability list at Plugins list. |
| 194 |
3. Vulnerability list at Site Health. |
| 195 |
|
| 196 |
== Compatibility == |
| 197 |
|
| 198 |
* WordPress: 5.6 - 7.1 |
| 199 |
* PHP: 7.0 - 8.5 |
| 200 |
* WP-CLI: 2.3.0 - 2.12.0 |
| 201 |
|
| 202 |
== Changelog == |
| 203 |
|
| 204 |
= [5.1.2] - 2026-08-07 = |
| 205 |
|
| 206 |
**Fixed** |
| 207 |
|
| 208 |
* Missing `load_plugin_textdomain()` call caused a "Translation loading for the `wpvulnerability` domain was triggered too early" `_doing_it_wrong()` notice on WordPress 6.7+. The textdomain is now explicitly loaded on the `init` hook. |
| 209 |
|
| 210 |
**Added** |
| 211 |
|
| 212 |
* WordPress Playground blueprint (`blueprint.json`) with pre-installed vulnerable plugins and a theme for quick testing. |
| 213 |
|
| 214 |
**Changed** |
| 215 |
|
| 216 |
* Security vulnerability reporting link updated to [ROBOTSTXT](https://www.robotstxt.es/contacto/). |
| 217 |
* Contributor repository link updated to [git.robotstxt.es/ROBOTSTXT/wpvulnerability](https://git.robotstxt.es/ROBOTSTXT/wpvulnerability). |
| 218 |
* The `readme.txt` Changelog section now shows only the latest 3 versions; the full history remains in `changelog.txt`. |
| 219 |
|
| 220 |
**Compatibility** |
| 221 |
|
| 222 |
* WordPress: 5.6 - 7.1 |
| 223 |
* PHP: 7.0 - 8.5 |
| 224 |
* WP-CLI: 2.3.0 - 2.12.0 |
| 225 |
|
| 226 |
**Tests** |
| 227 |
|
| 228 |
* PHP Coding Standards: 3.13.5 |
| 229 |
* WordPress Coding Standards: 3.3.0 |
| 230 |
* PHPStan: 2.1.55 (level 9, 0 errors) |
| 231 |
* PHPUnit: 9.6.34 (25 tests) |
| 232 |
|
| 233 |
= [5.1.1] - 2026-07-09 = |
| 234 |
|
| 235 |
**Fixed** |
| 236 |
|
| 237 |
* Site Health: the memcached, Redis, and SQLite vulnerability tests always returned "Invalid software type" because those components were missing from the software list. They now run correctly. |
| 238 |
* "Send test email" failed when no email recipients were configured: the forced-test path added the admin email but the send gate used a flag computed before the override. The test email now sends. |
| 239 |
* "Run notification now" reported failure when only webhook channels (Slack/Teams/Discord/Telegram) were enabled and email was disabled. The notification result now reflects whether any channel delivered successfully. |
| 240 |
* Weekly notification cron events were never auto-scheduled, because the `weekly` cron schedule was registered only at `init` while the on-load scheduling runs earlier. The weekly/daily schedule registration moved to the always-loaded scheduler so weekly notifications schedule correctly. |
| 241 |
* Deactivation deleted the per-component analysis settings (`wpvulnerability-analyze`), so deactivating and reactivating reset which components were hidden. Analysis settings are now preserved on deactivation (only uninstall removes them). |
| 242 |
* The debug "Cron Status" panel always showed the notification event as "not scheduled" because it checked the wrong hook name (`wpvulnerability_send_notification` instead of `wpvulnerability_notification`). |
| 243 |
* The debug "last run" timestamp was always empty because it read a `wpvulnerability-logs` option that is never written; it now reads the most recent API log entry. |
| 244 |
* Redis detection called `close()` twice on the success path (once in the `try` block, once in `finally`); the redundant close was removed. |
| 245 |
* The single-site vulnerable-themes count was hardcoded to `0` instead of reading the stored option. |
| 246 |
|
| 247 |
**Changed** |
| 248 |
|
| 249 |
* Single-site email recipient sanitization now uses `is_email()` for strict validation, matching the multisite behaviour. |
| 250 |
* Removed a redundant nonce field from the single-site "Reset Plugin" form (the form only submits the full-reset action). |
| 251 |
* Removed dead code: the unused `wpvulnerability_sanitize_messages` callback and its setting registration, and an unused `$tools_action` variable in the multisite admin. |
| 252 |
|
| 253 |
**Compatibility** |
| 254 |
|
| 255 |
* WordPress: 5.6 - 7.1 |
| 256 |
* PHP: 7.0 - 8.5 |
| 257 |
* WP-CLI: 2.3.0 - 2.12.0 |
| 258 |
|
| 259 |
**Tests** |
| 260 |
|
| 261 |
* PHP Coding Standards: 3.13.5 |
| 262 |
* WordPress Coding Standards: 3.3.0 |
| 263 |
* PHPStan: 2.1.55 (level 9, 0 errors) |
| 264 |
* PHPUnit: 9.6.34 (25 tests) |
| 265 |
|
| 266 |
= [5.1.0] - 2026-07-08 = |
| 267 |
|
| 268 |
**Security** |
| 269 |
|
| 270 |
* `wpvulnerability_validate_shell_command()` now uses exact `in_array()` match instead of `stripos()` substring matching for the shell-command allowlist (defense-in-depth). |
| 271 |
* `wpvulnerability_detect_php()`, `wpvulnerability_detect_curl()`, and `wpvulnerability_detect_webserver()` now route through `wpvulnerability_safe_shell_exec()`, so every software-detection shell call is validated and recorded in the Shell Execution Audit Log. Previously these called `shell_exec()` directly, bypassing the wrapper and the audit log. As a side effect this also fixes nginx/angie version detection: `escapeshellcmd()` was escaping the `2>&1` redirect, so stderr (where nginx prints its version) was never captured. |
| 272 |
|
| 273 |
**Fixed** |
| 274 |
|
| 275 |
* Multisite uninstall fatal error: `Uncaught Error: Undefined constant "WPVULNERABILITY_PLUGIN_BASE"` when "Delete all plugin data on uninstall" was enabled. `uninstall.php` now defines the constant before loading `wpvulnerability-run.php`. |
| 276 |
* `WPVULNERABILITY_HIDE_*` constants now stop `shell_exec` detection for hidden components during scheduled scans and in the admin "Software Detection Methods" panel. Previously they only hid the results from the UI, so the audit log kept filling with "command not found" entries for components the administrator had explicitly deactivated. |
| 277 |
* `wpvulnerability_detect_webserver()` no longer shell-probes a hidden web server via the sibling path: `WPVULNERABILITY_HIDE_NGINX` and `WPVULNERABILITY_HIDE_APACHE` now fully isolate the hidden server. |
| 278 |
* Multisite cron requests on non-main subsites no longer load all plugin module files. No WPVulnerability cron events are scheduled on subsites, so the extra loading was wasted work. |
| 279 |
* LiteSpeed / OpenLiteSpeed / Caddy shell detection in the WP_DEBUG diagnostic panel now works: the commands no longer use `2>/dev/null` (which the shell-command validator rejected), `caddy` was added to the allowlist, and `which` output is validated as a real path so "command not found" messages are not mistaken for a detection. |
| 280 |
|
| 281 |
**Changed** |
| 282 |
|
| 283 |
* `Network: true` added to the plugin header to declare network-aware multisite behaviour. |
| 284 |
* Removed the unused `$plugin_status` parameter from `wpvulnerability_plugin_info_after()`; the PHPCS suite now passes with zero warnings. |
| 285 |
* Multisite network dashboard: the "Site Health" footer link pointed to `wp-admin/network/site-health.php`, which does not exist (Site Health is a per-site screen). It now links to the main site's `wp-admin/site-health.php`. |
| 286 |
|
| 287 |
**Compatibility** |
| 288 |
|
| 289 |
* WordPress: 5.6 - 7.1 |
| 290 |
* PHP: 7.0 - 8.5 |
| 291 |
* WP-CLI: 2.3.0 - 2.12.0 |
| 292 |
|
| 293 |
**Tests** |
| 294 |
|
| 295 |
* PHP Coding Standards: 3.13.5 |
| 296 |
* WordPress Coding Standards: 3.3.0 |
| 297 |
* PHPStan: 2.1.55 (level 9, 0 errors) |
| 298 |
* PHPUnit: 9.6.34 (18 tests) |
| 299 |
|
| 300 |
= Previous versions = |
| 301 |
|
| 302 |
If you want to see the full changelog, visit the [changelog.txt](https://plugins.trac.wordpress.org/browser/wpvulnerability/trunk/changelog.txt) file. |
| 303 |
|
| 304 |
== Security == |
| 305 |
|
| 306 |
This plugin adheres to the following security measures and review protocols for each version: |
| 307 |
|
| 308 |
* [WordPress Plugin Handbook](https://developer.wordpress.org/plugins/) |
| 309 |
* [WordPress Plugin Security](https://developer.wordpress.org/plugins/wordpress-org/plugin-security/) |
| 310 |
* [WordPress APIs Security](https://developer.wordpress.org/apis/security/) |
| 311 |
* [WordPress Coding Standards](https://github.com/WordPress/WordPress-Coding-Standards) |
| 312 |
* [Plugin Check (PCP)](https://wordpress.org/plugins/plugin-check/) |
| 313 |
|
| 314 |
== Privacy == |
| 315 |
|
| 316 |
* This plugin or the WordPress Vulnerability Database API does not collect any information about your site, your identity, the plugins, themes or content the site has. |
| 317 |
|
| 318 |
== Vulnerabilities == |
| 319 |
|
| 320 |
* A security vulnerability was found and fixed in version 4.2.2.1. All previous versions (3.3.0 - 4.2.1) are affected. Please update to version 4.2.2.1 or later. |
| 321 |
|
| 322 |
Found a security vulnerability? Please report it to us privately at [ROBOTSTXT](https://www.robotstxt.es/contacto/). |
| 323 |
|
| 324 |
== Contributors == |
| 325 |
|
| 326 |
You can contribute to this plugin at the [WPVulnerability repository](https://git.robotstxt.es/ROBOTSTXT/wpvulnerability). |
| 327 |
|
