Snow Monkey bbPress Support WP Registry grade D+. High-severity findings · 2 findingsWP RegistryHigh-severity findings · 2 findingsOpen the reportD+

High-severity findings.

Audited release

0.18.5

Findings

2

Worst severity

high

Content hash

f31987e1f2ecc8cb36f030f9… Copy

Findings

• high Unauthenticated REST read of hidden/private bbPress forum content

  information_disclosure

  App/Rest.php re-registers bbPress forum, topic, and reply post types with show_in_rest=true and rest_controller_class=WP_REST_Posts_Controller. WordPress core WP_REST_Posts_Controller::check_read_permission() returns true whenever post_status is 'publish' (or current_user_can('read_post')), and never consults bbp_user_can_view_forum() / bbp_exclude_forum_ids(). Topics and replies inside hidden or private forums remain post_status=publish; only the parent forum uses hidden/private. Collection queries may still be filtered by bbp_pre_get_posts_normalize_forum_visibility, but get_item loads the post by ID via get_post() and skips that query. An unauthenticated client who can guess or enumerate sequential IDs can GET /wp-json/wp/v2/topic/{id} and /wp-json/wp/v2/reply/{id} and receive title, rendered content, author, and excerpt for posts that bbPress would refuse to render on the front end. Re-registering via (array) get_post_type_object() also drops bbPress's custom capabilities map (including read_hidden_posts), so subscribers who hold read_private_forums can additionally read hidden forum objects themselves via /wp-json/wp/v2/forum/{id}.

  App/Rest.php:22-44

  Recommendation

  Do not expose bbPress post types through WP_REST_Posts_Controller. Keep show_in_rest false, or ship a custom controller whose get_item/get_items permission callbacks call bbp_user_can_view_forum() (and bbp_is_forum_hidden / bbp_exclude_forum_ids for children) before returning content. If Gutenberg support is required, gate writes and reads on bbPress caps rather than core post caps.

• medium Logged-in like AJAX allows unbounded meta writes and arbitrary user-meta increment

  missing_capability

  Both reply and topic like endpoints are registered for wp_ajax and wp_ajax_nopriv, with a nonce localized on every front-end page. The write path only requires a logged-in user whose ID is not equal to the client-supplied authorId. There is no check that replyId/topicId is a bbPress post the user can view, that authorId is the actual author, or that the current user has not already liked. array_unique() prevents duplicate user IDs in the liker list, but the integer count in post meta and the author's user meta is incremented on every request. Observable: a Subscriber can inflate any other user's public 'Total likes' on their bbPress profile, and can write smbbpress-support-stars / smbbpress-support-stars-users (and the topic-* keys) onto an arbitrary post ID. Unauthenticated callers cannot write (current_user->ID is 0) but still receive JSON of liker display names for any ID.

  App/Stars.php:94-114

  Recommendation

  Require is_user_logged_in() and drop nopriv if likes are login-only. absint() the IDs, verify the post type and that the current user can view the parent forum, require authorId to match the post author, and refuse the increment when the current user is already in the liker list. Apply the same checks in App/TopicStars.php::_update_stars().

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.