Powerhouse WP Registry grade D+. High-severity findings · 4 findingsWP RegistryHigh-severity findings · 4 findingsOpen the reportD+ #6 in Developer Tools

High-severity findings.

Audited release

3.5.5

Findings

4

Worst severity

high

Content hash

2deb164905bc34aa5e0b49f9… Copy

Findings

• high Shop Manager can create and promote administrators via the generic users REST API

  missing_capability

  Every Powerhouse REST route inherits ApiBase::permission_callback, which returns true for manage_options OR manage_woocommerce. WooCommerce Shop Manager has the latter and not the former, so they pass. POST /wp-json/v2/powerhouse/users and POST /users/{id} feed the body through WP::separator(..., 'user'), whose data_fields include 'role' and 'user_pass', then call wp_insert_user / wp_update_user with no promote_users, create_users, or get_editable_roles check. Observable: a Shop Manager (cookie + X-WP-Nonce from any wp-admin screen they can open, or an application password) POSTs role=administrator and becomes, or creates, a full administrator. The same gate also exposes DELETE /users, POST /users/resetpassword (retrieve_password for arbitrary ids), GET /users?meta_keys[]= (arbitrary usermeta), POST /upload, GET /shortcode?shortcode= (do_shortcode), GET /lc (license codes), GET /plugins, and full post/term/product/order CRUD for any post type — far beyond Shop Manager's native caps. The Powerhouse admin SPA itself is manage_options-only, so this is not 'the UI the shop manager is supposed to use'; it is a hidden REST privilege-escalation surface.

  inc/classes/Domains/User/Core/V2Api.php:34-75,196-266,277-308

  Recommendation

  Default the REST permission_callback to manage_options only (matching the admin menu). For WooCommerce resources, require the matching WooCommerce cap (manage_woocommerce / edit_shop_orders / edit_products) per route, not globally. On user create/update, reject role changes unless current_user_can('promote_users') and the target role is in get_editable_roles(). Never pass an attacker-supplied role into wp_insert_user/wp_update_user.

• high Shop Manager can inject stored XSS/skimmer CSS via powerhouse_settings echoed on every frontend page

  xss_stored

  POST /wp-json/v2/powerhouse/options (same manage_woocommerce gate) calls Settings::partial_update() and writes any Settings property, including theme and theme_css, to option powerhouse_settings. Theme::print_css() then echoes those values unsanitized inside a <style> block on wp_head (priority -100, every public page including WooCommerce checkout/cart/my-account). FrontEnd::add_html_attr() interpolates theme into the <html data-theme="..."> attribute with no esc_attr. A Shop Manager can set theme to x"></html><script>…</script> or theme_css values to </style><script>…</script><style> and execute JavaScript in every visitor and administrator browser that loads the storefront — a checkout skimmer vector. GET /options also returns bunny_stream_api_key in plaintext to the same role.

  inc/classes/Theme/Model/Theme.php:241-252

  Recommendation

  Restrict options POST to manage_options. Allowlist theme names against the known daisyUI set. Escape theme for HTML attributes (esc_attr) and CSS values (e.g. only permit oklch/hex/length tokens). Do not echo arbitrary theme_css strings into <style>. Do not return bunny_stream_api_key to roles that cannot manage_options.

• high Unauthenticated REST endpoint deletes stored license codes and disables power-* plugins

  missing_auth

  POST /wp-json/v2/powerhouse/lc/invalidate (and the deprecated POST /wp-json/powerhouse/lc/invalidate) is registered with permission_callback __return_true. The handler reads product_slug from JSON and calls Base::delete_lc_transient(), which unsets that slug in option powerhouse_license_codes and delete_transient('lc_{slug}'). No nonce, capability, or authentication. PluginTrait::check_required_plugins only invokes each power-* plugin's bootstrap when LC::ia($kebab) is true (transient post_status === 'activated'); after invalidate, ia() is false and those plugins fail closed. Observable: curl -X POST -H 'Content-Type: application/json' -d '{"product_slug":"power-shop"}' /wp-json/v2/powerhouse/lc/invalidate from an unauthenticated visitor (or a CSRF from a logged-in browser) drops that product's license until an administrator re-activates. The handler also writes the attacker-supplied slug into WooCommerce logs (leftover debug).

  inc/classes/Domains/LC/Core/V2Api.php:44-48,143-171

  Recommendation

  Require manage_options (or a signed webhook secret from the license server) on lc/invalidate. If the license server must push invalidations, authenticate with HMAC over the body rather than __return_true. Do not delete the saved code option on a cache-bust; only delete the transient. Remove the leftover WC::log debug line.

• high Hardcoded WordPress application passwords for the production license server

  hardcoded_credentials

  Api\Base::init() embeds live Basic-Auth credentials for the power-partner-server REST API, selected by wp_get_environment_type(): production user powerpartner / application password uJsk Gu3S pwUG r6ia P9zy Xjrj against https://cloud.luke.cafe, plus distinct staging and local (including IS_HOME) passwords. Those values are compiled into every distributed copy of the plugin (public GitHub repo zenbuapps/wp-powerhouse). The same class uses them on every license activate/deactivate call. Anyone who reads the plugin can impersonate the powerpartner application-password user on the vendor license API (activate/deactivate codes, and any other routes that user can hit). This does not by itself authenticate to the local WordPress site, but it compromises the license authority every site trusts.

  inc/classes/Api/Base.php:51-88

  Recommendation

  Rotate and revoke every leaked application password on cloud.luke.cafe, cloud-staging.wpsite.pro, and local. Stop shipping shared credentials in the plugin. Authenticate license calls with a per-site secret (the license code itself HMAC'd, or a site-specific API key issued at activation) stored only in the site's options, not in source.

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.