AntiConférences WP Registry grade D+. High-severity findings · 4 findingsWP RegistryHigh-severity findings · 4 findingsOpen the reportD+

High-severity findings.

Audited release

1.0.3

Findings

4

Worst severity

high

Content hash

37e7b7caff96bd7a370f7d3f… Copy

Findings

• high Email validation token is url-safe base64 of the voter address

  predictable_token

  Anonymous supports are held until the voter visits a camp URL with ?key-support=. The plugin stores and later compares that parameter as anticonferences_urlsafe_b64encode(comment_author_email) — a deterministic encoding of the email, not a random secret, with no expiry or HMAC. anticonferences_template_redirect() is unauthenticated: if delete_metadata('comment', null, '_ac_support_email', $_GET['key-support'], true) succeeds, it decodes the same value and wp_set_comment_status(..., 'approve') on every held ac_support for that email (not scoped to the current camp). After that, anticonferences_support_allowed() treats any later ac_support from that address as approved. Combined with flood/duplicate checks being disabled for ac_support, an unauthenticated attacker who can POST /wp-comments-post.php (camps force comments_open until the closing date) invents addresses, computes the key, and stuffs _ac_support_count, which AC_Walker_Topic and the admin topics column display as the public heart total. Anyone who knows a real attendee email can also validate votes in that person's name without inbox access.

  inc/functions.php:361-365,741-750,833-864

  Recommendation

  Replace the key with a high-entropy per-support (or per-email) secret stored as comment meta (wp_generate_password / random_bytes), bind it to the camp ID, expire it, and compare with hash_equals. Do not derive the token from the email. Scope approval to supports that actually hold that token.

• medium Attacker-controlled ac_comment_type applies camp voting logic to every post

  missing_auth

  preprocess_comment copies $_POST['ac_comment_type'] into comment_type whenever it is ac_topic or ac_support, with no check that comment_post_ID is a camps post. anticonferences_support_can_flood_and_dupe() then returns false from duplicate_comment_id and wp_is_comment_flood for that POST flag (priority 11, after core's flood callback), so unauthenticated visitors can disable site-wide comment flood and duplicate protection on any post that still has comments open. anticonferences_pre_comment_approved() forces ac_topic to pending, but for ac_support it calls anticonferences_support_allowed(), which returns 1 for every logged-in user (Subscriber included) without comparing the post type. Quota is skipped when _camp_votes_amount is absent (regular posts). Observable consequence: a Subscriber POSTing comment=...&ac_comment_type=ac_support&comment_post_ID=<any open post> gets an auto-approved comment that default wp_list_comments() (empty type) will render, bypassing comment_moderation / comment_previously_approved; guests can flood the comments table by repeating the same flag.

  inc/functions.php:344-351,411-424,465-473,484-516

  Recommendation

  Apply preprocess_comment, flood/dupe overrides, and pre_comment_approved only when get_post_type($comment_post_ID)==='camps'. Restrict support_allowed()'s logged-in shortcut to that post type and to the current user's email. Do not let ac_comment_type be set on arbitrary posts.

• medium Topic support removal deletes arbitrary comments (IDOR)

  missing_capability

  On load-comment.php, before comment.php's current_user_can('edit_comment') check, anticonferences_admin_load_edit_comments() treats ?c=<ac_topic id>&remove_support=<id> as a delete. After check_admin_referer('topic_remove_support_'.$topic_id) it fetches $support but never uses it: wp_delete_comment($support_id) is called with no verification that the target is an ac_support child of that topic, and no current_user_can on the target. The handler then wp_safe_redirect/exit, so core's capability gate never runs. An Author who can edit one of their camp topics (edit_comment maps to edit_post on that camp) receives a valid nonce on the Supports metabox and can substitute any comment ID, including comments on other authors' posts they cannot moderate. Editors/admins can already delete comments via core; the privilege jump is Author (and anyone else with edit_comment on a single topic) to site-wide comment deletion.

  inc/admin.php:451-479

  Recommendation

  Require current_user_can('edit_comment', $topic_id) and current_user_can('edit_comment', $support_id). Refuse unless $support->comment_type==='ac_support' and (int)$support->comment_parent===(int)$topic_id. Prefer wp_trash_comment over an unscoped delete.

• medium Support counter increments for any approved reply, not only ac_support

  unsafe_input

  anticonferences_increment_support_count is hooked to wp_insert_comment (all comment types) as well as comment_approved_ac_support. It returns early only when comment_approved is empty; it never checks comment_type==='ac_support'. For any approved comment it does $count += (int) $support->comment_content and update_comment_meta($parent, '_ac_support_count', $count). Camps force comments_open, and topic IDs are printed as data-topic-id on the front end. A Subscriber (or a guest on a site that auto-approves comments) POSTing to wp-comments-post.php with comment_post_ID=<camp>, comment_parent=<topic id>, and comment=999 — without ac_comment_type — stores a regular comment and adds 999 to the public heart total used by AC_Walker_Topic and the 'Most supported' order. Quota and email validation do not apply because the row is not ac_support. Trashing that regular comment does not decrement the meta (decrement hooks only comment_trash_ac_support / comment_spam_ac_support), so the inflation sticks.

  inc/functions.php:905-916

  Recommendation

  Return unless $support->comment_type==='ac_support' and the parent is an ac_topic on a camps post. Recalculate _ac_support_count from approved ac_support children instead of adding comment_content from unrelated replies.

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.