High-severity findings.

Audited release

1.0.6

Findings

2

Worst severity

high

Content hash

037ef598b73eb1443dda9d0f… Copy

Findings

• high Protected account pages are readable via REST API, public archives, and core sitemaps

  auth_bypass

  The plugin's only access control for protect_page is RS_Account_Pages_Account::check_page_access() on template_redirect, and it returns immediately unless is_singular('account-page'). The CPT is registered public, has_archive true, and show_in_rest true with the default WP_REST_Posts_Controller, so published account pages — including those with Protection enabled — are returned in full by GET /wp-json/wp/v2/account-page and GET /wp-json/wp/v2/account-page/{id} to unauthenticated clients. The same posts are queryable on the /account/ archive whenever get_current_menu() is empty (redirect_account_page_archive returns without blocking), and they appear in WordPress core sitemaps because exclude_from_sitemap only hooks wpseo_sitemap_exclude_post_type, not wp_sitemaps_post_types. There is no rest_account-page_query, rest_prepare_account-page, pre_get_posts, or the_posts filter applying can_access_page(). Observable result: an anonymous request to the REST collection/item endpoints returns content.rendered of a page that wp_die()s with 403 on the singular permalink.

  includes/account.php:45-58,218-240

  Recommendation

  Enforce can_access_page() on every read path, not only singular templates: filter rest_account-page_query / rest_prepare_account-page (and item permissions) to hide or 403 protected posts; exclude them from archives via pre_get_posts; exclude the CPT from core sitemaps (wp_sitemaps_post_types) in addition to Yoast; and do not render the post type archive when the visitor has no menu (404/redirect instead of listing all pages).

• medium Menu access conditions are OR-matched despite UI text requiring all conditions

  auth_bypass

  Account page protection is 'page is in the visitor's active menu'. Menus are chosen by RS_Account_Pages_Utility::user_meets_conditions(), which sets true and breaks on the first matching condition (OR). The ACF menus repeater instructs 'The first menu that meets all conditions will be used for the account page' and the Condition(s) field is a multi-select that includes both logged_in and not_admin. A typical non-admin member menu configured as logged_in + not_admin therefore matches unauthenticated users because user_can(0, 'manage_options') is false, so not_admin inverts to true. get_current_menu() then assigns that menu, can_access_page() returns true for every page in it (including hidden items), and check_page_access() allows the singular view. Opposite pairs (logged_in/logged_out, admin/not_admin) similarly collapse to everyone under OR. Empty conditions already mean always-true by design.

  includes/utility.php:160-173

  Recommendation

  Match the documented behavior: require every selected condition to pass (AND), and keep never_show as an unconditional auto-select blocker. If OR is intended, change the settings copy and prevent combining opposite conditions. Add tests for [logged_in, not_admin] so anonymous users do not inherit the member menu.

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.