WDS Blocks WP Registry grade A-. Low-severity findings · 1 findingWP RegistryLow-severity findings · 1 findingOpen the reportA-

Low-severity findings only.

Audited release

2.2.0

Findings

1

Worst severity

low

Content hash

149458862f44f90d1c5adf71… Copy

Findings

• low Production release ZIP ships WP-CLI, Composer, and PHP_CodeSniffer in web-accessible vendor/

  dev_tool_in_production

  The GitHub 2.2.0 WDS-Blocks.zip was built with `composer install` (dev=true) instead of `--no-dev`. composer.json only runtime-requires composer/installers; require-dev pulls wp-cli/wp-cli-bundle ^2.5 (WP-CLI 2.5.0 including eval, eval-file, shell, db, config, plugin/theme install), squizlabs/php_codesniffer (phpcs/phpcbf), and Composer itself 2.1.3. Those land in vendor/bin as executable PHP (phpcs, phpcbf, composer, jsonlint, validate-json, export-plural-rules) with no ABSPATH guard; Composer only prints a SAPI warning then still bootstraps Application::run() with display_errors=1. wds-blocks.php never includes vendor/autoload.php, and .gitignore lists vendor/, so this tree is unused at runtime but web-reachable under wp-content/plugins. WP-CLI's own boot-fs.php correctly refuses non-CLI. On PHP-FPM, empty argv typically yields usage text rather than file rewrite/RCE, so this is unnecessary attack surface rather than a confirmed unauth RCE. Last shipped zip is 2021-06-28; GitHub 2.2.2 (block_categories_all) has no zip asset.

  composer.json:17-25

  Recommendation

  Rebuild the release zip with `composer install --no-dev --no-scripts` or omit vendor/ entirely (the plugin does not autoload it). Do not ship vendor/bin, WP-CLI, PHP_CodeSniffer, or Composer in a WordPress plugin directory. Add an index.php/deny rule if any vendor must remain.

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.