ROBOTSTXT/wpvulnerability
ROBOTSTXT/wpvulnerability
Watch
0
0
Fork
You've already forked wpvulnerability
 0
Code Issues Pull requests Releases 6 Activity
6 releases 6 tags
  • 5.1.6 e6cba7ef6a

    v5.1.6 Stable

    javier released this 2026-08-23 07:10:06 +00:00 | 0 commits to main since this release

    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.

    Changed

    • languages/wpvulnerability.pot regenerated with the new strings.

    Compatibility

    • WordPress: 4.7 - 7.1
    • PHP: 7.0 - 8.5
    • WP-CLI: 2.3.0 - 2.12.0

    Tests

    • 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)

    5.1.5 - 2026-08-22

    Changed

    • The contributor list now leads with the ROBOTSTXT organization account, followed by Javier Casares; the remaining contributors are unchanged.
    • Regenerated languages/wpvulnerability.pot so 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.

    Compatibility

    • WordPress: 4.7 - 7.1
    • PHP: 7.0 - 8.5
    • WP-CLI: 2.3.0 - 2.12.0

    Tests

    • 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)
      = [5.1.4] - 2026-08-22 =

    Highlights

    • 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.

    Fixed

    • The Site Health integration registered its tests behind class_exists( 'WP_Site_Health' ), but core loads that class lazily, after init, 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-data timestamp 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 calls wp_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.

    Security

    • 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.php supersedes 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.

    Changed

    • 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.

    Compatibility

    • 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.

    Tests

    • 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)

    5.1.3 - 2026-08-22

    Added

    • wpvulnerability-compat.php: verbatim WordPress core function polyfills (wp_doing_cron, get_main_site_id, wp_is_json_request, sanitize_locale_name, determine_locale, wp_timezone_string, wp_timezone, wp_date, get_post_datetime, get_post_timestamp), each guarded by function_exists(). The plugin no longer fatals on WordPress versions that lack these functions.

    Security

    • The API connectivity test results (message, HTTP code, response time and the raw response preview) are now escaped client-side before being inserted into the page, in both single-site and network admin. Remote API responses could previously inject arbitrary HTML.
    • The debug export and the Database Options Viewer now mask webhook URLs, Telegram bot tokens/chat IDs and notification email addresses, so shared debug files never contain usable secrets.
    • The multisite "components to hide" save now routes through the strict sanitizer, so a crafted request can no longer re-enable analysis of components force-hidden with WPVULNERABILITY_HIDE_* constants.
    • API responses are only cached when the HTTP status is 200 and the body is valid JSON. Error responses (4xx/5xx, HTML error pages) were previously cached for the full TTL and blocked retries.
    • API request URLs are now built from whitelisted types and sanitized slugs/versions (wpvulnerability_get(), wpvulnerability_get_vulnerabilities()).

    Fixed

    • Cron scheduling ran wp_get_schedules() (and other plugins' cron_schedules callbacks, including their translation calls) before init on every request. Core and notification event scheduling moved to init, matching the WordPress 6.7+ translation-loading requirements.
    • Deactivation now removes the wpvulnerability-plugins-data and wpvulnerability-plugins-data-cache options created at activation.
    • The notification cron period is validated against daily/weekly before wp_schedule_event(), so a corrupted configuration value can no longer silently unschedule notifications.
    • The admin menu vulnerability counters escape the badge title attribute, and the plugin row "Settings" link escapes its URL and label.
    • Application Passwords REST authentication is gated on function_exists( 'wp_is_application_passwords_available' ) so WordPress < 5.6 no longer fatals on unauthenticated REST requests; cookie-authenticated admin sessions keep working and the Application Passwords functionality itself is simply unavailable on old versions.
    • The Site Health integration registers its tests only when WP_Site_Health exists (WordPress 5.2+); on older versions the plugin runs without the Site Health section.

    Changed

    • Minimum WordPress version lowered from 5.6 to 4.7. Whole functionalities degrade gracefully on old versions: Application Passwords REST authentication (WordPress 5.6+) and the Site Health integration (WordPress 5.2+) are only registered when available; everything else works through the polyfills.

    Compatibility

    • WordPress: 4.7 - 7.1
    • PHP: 7.0 - 8.5
    • WP-CLI: 2.3.0 - 2.12.0

    Tests

    • PHP Coding Standards: 3.13.6
    • WordPress Coding Standards: 3.4.1
    • PHPStan: 2.2.9 (level 9, 0 errors)
    • PHPUnit: 9.6.36 (37 tests)
    Downloads