High-severity findings.

Audited release

1.3.0

Findings

2

Worst severity

high

Content hash

6fdec4e47e89fd88da839f47… Copy

Findings

• high Subscriber+ arbitrary plugin activation via wp_ajax_dependency_installer

  missing_capability

  The plugin constructor always runs WP_Dependency_Installer::instance(__DIR__)->run(), which loads wp-dependencies.json and registers wp_ajax_dependency_installer → ajax_router. ajax_router reads unsanitized $_POST['method'] and $_POST['slug'] with no wp_verify_nonce/check_ajax_referer (phpcs explicitly disables NonceVerification) and dynamically calls $this->$method($slug) for method in {install, activate, dismiss}. activate() immediately calls activate_plugin($slug) (or network-wide activate_plugin when is_network_admin()) with no current_user_can('activate_plugins') and without requiring $slug to be a configured dependency — the config lookup is only used afterward to build a success message. WordPress core activate_plugin() does not check capabilities. wp_ajax_ fires for every authenticated user, including WooCommerce Customer (read-only, equivalent to Subscriber) posting to admin-ajax.php from the storefront; the admin_notices UI gate (update_plugins) does not apply to the AJAX action. Observable: POST action=dependency_installer&method=activate&slug=hello.php (or any installed plugin file) as a customer activates that plugin and runs its activation hooks. This is the unfixed WP Dependency Installer 3.1.0 issue disclosed in 2022 and patched upstream in 4.3.1 (nonce plus current_user_can('activate_plugins')). This plugin's 1.3.0 release (2025-10-09) still vendors 3.1.0.

  vendor/afragen/wp-dependency-installer/wp-dependency-installer.php:91-97,346-358,499-516

  Recommendation

  Upgrade afragen/wp-dependency-installer to >= 4.3.1 (adds wp_verify_nonce('wp-dependency-installer_'.$slug) and current_user_can('activate_plugins') in activate()). Alternatively stop calling WP_Dependency_Installer::run() — GitHub Updater is only an optional notice. Until then, reject ajax_router unless current_user_can('activate_plugins') / 'install_plugins', verify a nonce, and allowlist $slug against $this->config before activate_plugin().

• medium CSRF can install GitHub Updater from the develop branch

  csrf

  The same ajax_router has no CSRF nonce. install($slug) does check current_user_can('update_plugins') but that only stops low-privilege callers; a logged-in administrator who visits an attacker page can be forced to POST action=dependency_installer&method=install&slug=github-updater/github-updater.php. admin_footer prints jQuery that posts those fields with no nonce. install() then Plugin_Upgrader->install()s $this->config[$slug]['download_link'], which apply_config() sets to https://api.github.com/repos/afragen/github-updater/zipball/develop for the shipped wp-dependencies.json (optional GitHub Updater from the develop branch). The 'nonce' passed into WPDI_Plugin_Installer_Skin is wp_nonce_url(download_link) — a query-arg on the GitHub URL, not a verified request nonce. Combined with finding 1, a customer can then activate the newly installed plugin. Observable: after the admin CSRF, github-updater appears under wp-content/plugins/ from the GitHub develop zipball.

  vendor/afragen/wp-dependency-installer/wp-dependency-installer.php:312-327,346-358,417-432

  Recommendation

  Same fix as finding 1: WPDI >= 4.3.1 verifies a per-slug nonce before install/activate. Pin GitHub Updater to a tagged release instead of branch develop, or drop the optional dependency installer entirely if the notice is not needed.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.