WCPOS Polylang Integration WP Registry grade C-. High-severity findings · 1 findingWP RegistryHigh-severity findings · 1 findingOpen the reportC-

High-severity findings.

Audited release

0.1.2

Findings

1

Worst severity

high

Content hash

773d8ee4276691d0b51f9985… Copy

Findings

• high Unauthenticated rest_pre_dispatch fast-sync intercept leaks POS catalogue IDs

  missing_auth

  Plugin::maybe_intercept_fast_sync is hooked to rest_pre_dispatch at priority 20 with no capability or nonce check. WordPress applies rest_pre_dispatch before match_request_to_handler and before permission_callback; a non-null return is served as the REST response. When Polylang is active, a request whose route is /wcpos/v1/products, /wcpos/v1/products/variations, or /wcpos/v1/products/{id}/variations, with posts_per_page=-1 and fields limited to id or id+date_modified_gmt, is answered with every published product/variation ID (and optional GMT modified timestamp) in the default language. That set includes POS-only products: query_fast_sync_payload uses post_status=publish and only excludes online-only IDs when pos_only_products is enabled. The intended WCPOS access_woocommerce_pos gate lives on WCPOS\WooCommercePOS\API::rest_pre_dispatch (priority 10), but that class is constructed only when woocommerce_pos_request() is true during rest_api_init. rest_api_init runs on init, before parse_request fills rest_route / wcpos query vars, so unmarked pretty-permalink traffic to /wp-json/wcpos/v1/products never loads the gate. An unauthenticated visitor or a Subscriber therefore GET /wp-json/wcpos/v1/products?posts_per_page=-1&fields=id with no X-WCPOS header and receives the ID dump. The same handler runs WP_Query with posts_per_page=-1 and cache_results=false, so the request is also an unauthenticated full-catalogue query. WCPOS's own fast-sync (wcpos_get_all_posts) is correctly reached via rest_dispatch_request after permission_callback; this plugin should not have moved the equivalent onto rest_pre_dispatch without re-implementing the same cap check.

  includes/class-plugin.php:119-147

  Recommendation

  Do not serve a REST payload from rest_pre_dispatch without an explicit capability check. Fail closed unless current_user_can('access_woocommerce_pos') (and treat a missing cap as denied). Better: move the intercept to rest_dispatch_request so the matched route's permission_callback runs first, matching WCPOS's own wcpos_get_all_posts. Cap posts_per_page and enable query caching. Add woocommerce-pos to Requires Plugins so the companion gate cannot be absent.

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.