Disciple.Tools - 3/3rds Meetings WP Registry grade D+. High-severity findings · 4 findingsWP RegistryHigh-severity findings · 4 findingsOpen the reportD+

High-severity findings.

Audited release

1.0.1

Findings

4

Worst severity

high

Content hash

a499d0f669eaf434c1fbf2f8… Copy

Findings

• high Unauthenticated REST self-registration ignores users_can_register and creates CRM groups

  missing_auth

  DT_33_Magic_Link::add_endpoints registers POST/GET/PUT /wp-json/threethirds/v1/login with permission_callback validate_request(), which the login subclass never overrides and which the base class implements as return true. dt_allow_rest_access authorize_url opens the same path to logged-out REST. resolve_endpoint concatenates strtolower(method)+'_'+action, so an unauthenticated POST with action=register calls DT_33_Login_Controller::post_register. That function passes request username/password/email straight to wp_create_user() — which does not consult users_can_register, does not send a verification email, and assigns get_option('default_role') (subscriber by default; whatever role the site admin set, including a Disciple.Tools multiplier). It then wp_set_current_user() and, for each groups[] title, DT_33_Groups_Repository::create() → DT_Posts::create_post('groups', $params, false, false), skipping Disciple.Tools capability checks. The public SPA at /threethirds/login exposes Create Account. After POST action=login (wp_set_auth_cookie) a GET to /3/3 auto-activates threethirds_app_magic_key for that user. Observable: new wp_users row and groups posts on a site that disabled registration; if default_role was raised, the new user inherits that role's DT access. No rate limit, nonce (logged-out REST), or admin toggle (admin UI is commented 'todo version 1.1').

  magic-link/controllers/login-controller.php:54-78

  Recommendation

  Do not ship open registration on a Disciple.Tools site unless an administrator explicitly enables it. Gate post_register on get_option('users_can_register') (and/or a plugin setting defaulting off), require a nonce or invite token, verify email before the user can log in, and never call DT_Posts::create_post with check_permissions=false. Override validate_request for the login route so register is not anonymously callable; keep login behind the same anti-abuse controls as wp-login.php.

• high Magic-link PUT creates Disciple.Tools groups with permissions disabled; WP_Error is treated as a found meeting

  missing_capability

  DT_33_Groups_Repository::create() always calls DT_Posts::create_post('groups', $params, false, false). put_meeting maps any non-numeric groups[] value through that create path before saving the meeting. The not-found guard is if (!$meeting), but DT_Posts::get_post returns a WP_Error object when the ID is missing or the current user cannot view it, and a WP_Error is truthy — so the 404 is skipped and group creation still runs. Any user who can mint a magic key can therefore insert groups posts. Minting is trivial: DT_33_Magic_Redirect on GET /3/3 calls activate() for every logged-in user (comment: 'let the admin share an easy link'), including a subscriber who just self-registered via finding 1. login_for_request then sets current_user to that subscriber; create_post with check_permissions=false ignores that they lack create_groups. Observable: new rows in the groups post type visible to dispatchers/admins and in DT reporting, with attacker-chosen titles. Meeting update itself still uses DT_Posts::update_post with permissions on and usually fails for a subscriber after the groups have already been created.

  magic-link/controllers/app-controller.php:106-147

  Recommendation

  Use is_wp_error() (and return) before mutating anything in put_meeting/get_meeting. Call DT_Posts::create_post with check_permissions true (default). Only create groups when the magic-link user can_create('groups'). Do not auto-activate the app for arbitrary logged-in roles on GET /3/3; require an admin-enabled app tile / role allow-list.

• medium Full WP_User object including password hash localized into magic-link JavaScript

  information_disclosure

  DT_33_Magic_Link::localizations() sets 'user' => wp_json_encode( wp_get_current_user() ) and wp_localize_script's it as magicLink. AppContext.js JSON.parse()s that value. WP_User's public $data is the wp_users row, so a cookie-authenticated visit to /threethirds/app/{key} (the normal post-login redirect from /3/3) embeds user_pass (phpass/bcrypt hash), user_email, user_activation_key, roles, and allcaps in page HTML/JS. user_activation_key is the password-reset secret; if a reset is in flight, wp-login.php?action=rp&key=…&login=… completes account takeover without cracking. The hash is usable for offline guessing and credential reuse. The login page localizes the same key (usually user 0). This is not required for the SPA — only ID/display name/capabilities are used.

  magic-link/magic-link.php:77-85

  Recommendation

  Localize only safe fields (ID, display_name, roles). Never json_encode a WP_User. If a reset key must exist, it belongs in usermeta, not the frontend.

• low No release since 1.0.1 (2022); Tested up to WordPress 5.6; admin settings never shipped

  unmaintained

  The 1.0.1 GitHub release is dated 2022-07-22. version-control.json still says last_updated 2021-03 and tested 5.7; the plugin header says Tested up to: 5.6 and requires Disciple.Tools theme 1.19. The constructor comments out admin/admin-menu-and-tabs.php as 'todo version 1.1' while plugin_row_meta still links to admin.php?page=dt33_settings. Master received a PHP 8.2 dynamic-property fix in 2024 but no new tag, so PUC still serves this 1.0.1 zip. The registration and group-create issues above were never patched in a release. Disciple.Tools sites running current WordPress/theme versions are carrying an unmaintained public login surface.

  disciple-tools-three-thirds.php:1-14,100-103

  Recommendation

  If the project is alive, cut a 1.1+ release that closes registration by default, restores a settings toggle, and re-tests on current WordPress and Disciple.Tools. Otherwise remove the plugin and use in-theme meeting fields / a maintained magic-link app.

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.