SNN Client Comments WP Registry grade B. Medium-severity findings · 2 findingsWP RegistryMedium-severity findings · 2 findingsOpen the reportB

Medium-severity findings.

Audited release

0.10

Findings

2

Worst severity

medium

Content hash

2980a715e93b674252279df5… Copy

Findings

• medium Comment AJAX has no capability check; any Subscriber can read and write the private overlay

  missing_capability

  The visual comment UI is hidden from logged-out visitors (snn_cc_enqueue_scripts returns unless is_user_logged_in() or a valid guest token) and guests are secret-gated, but every logged-in role is treated as a collaborator. wp_ajax_snn_cc_get_all_comments / snn_cc_get_comments / snn_cc_save_comment / snn_cc_update_comment / snn_cc_delete_comment / snn_cc_check_comment only call check_ajax_referer('snn_cc_nonce') then is_user_logged_in() || snn_cc_is_guest_user() — there is no current_user_can, role allowlist, or setting to restrict access. Defaults are snn_cc_enabled=1 and snn_cc_show_in_frontend=1, and the admin-bar CC menu is added for every logged-in frontend user, so the nonce is on any page a Subscriber can load. Observable: a customer/Subscriber POSTs action=snn_cc_get_all_comments and receives every active row (comment text, page_url, user display_name, positions); snn_cc_save_comment inserts into {$prefix}snn_client_comments for an arbitrary page_url; snn_cc_check_comment overwrites checked_by on any thread. Settings remain manage_options. This is not unauth on a default install (guest_commenting defaults to 0).

  snn-client-comments.php:687-690,2406-2443,2448-2461,2668-2719,2724-2758

  Recommendation

  Add a capability/role setting (e.g. edit_posts or a custom cap granted only to client accounts) and require current_user_can() in every comment AJAX handler and before enqueueing the overlay. Do not treat is_user_logged_in() as sufficient on sites with open registration or WooCommerce customers. Keep the manage_options settings page as-is.

• medium Guest share token is returned in comment JSON to every authorized reader

  information_disclosure

  snn_cc_get_global_guest_token() stores a bin2hex(random_bytes(32)) secret in option snn_cc_global_guest_token and the admin settings page is the only intended reveal (manage_options share URL). Both snn_cc_get_comments and snn_cc_get_all_comments SELECT c.guest_token (copied onto every guest insert from POST/session) and wp_send_json_success() the full row to any caller who passes the logged-in-or-guest gate. The frontend JS only needs that field to compare comment.guest_token == currentGuestToken for Edit/Delete buttons; a boolean can_edit from the server would suffice. Observable once snn_cc_guest_commenting=1 and at least one guest comment exists: a Subscriber reads guest_token from the JSON and constructs /?snn_guest_token=<value>, which snn_cc_validate_guest_token() accepts. That enables unauthenticated get/save/update/delete (shared guest identity can also delete any guest-owned parent and all of its replies, including staff replies). Token is not leaked on a default install because guest commenting defaults to off and logged-in comments store guest_token NULL.

  snn-client-comments.php:2425-2440,2475-2516,2740-2755

  Recommendation

  Stop selecting guest_token in AJAX responses. Compute ownership server-side and return can_edit/can_delete booleans. Do not persist the global share secret on each comment row; key guest ownership with a non-secret id (or HMAC) that is useless as a share URL. If a token must be sent to the current guest, send it only to that guest, never to logged-in users.

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.