High-severity findings.

Audited release

1.7

Findings

1

Worst severity

high

Content hash

8e39e2f3061591780ce611af… Copy

Findings

• high Unauthenticated IDOR on prayer-list REST: magic key never verified, parts.post_id is the only ACL

  auth_bypass

  DT_Prayer_List_Magic_Link::add_endpoints registers POST /wp-json/prayer_list_app/v1/daily with permission_callback __return_true. The inherited DT_Magic_Url_Base::authorize_url filter opens that URI to anonymous callers via dt_allow_rest_access, which is the intended magic-link pattern — but only if the SHA256 public_key in parts is bound to the claimed post_id. endpoint() never instantiates DT_Magic_URL or calls verify_rest_endpoint_permissions_on_post (the check later Disciple.Tools plugins use). After a missing-params check and dt_recursive_sanitize_array it switches on action and passes the client parts straight into SQL. endpoint_get_all / endpoint_get / endpoint_filter / endpoint_filter_lists all query dt_post_user_meta and dt_share WHERE user_id = parts.post_id and return post_title (contact/group names), tags, and prayer timestamps. The status query is broader than the prayer list: every record shared with that user that has overall_status, group_status, or status = 'active'. action=log takes an arbitrary post_id, loads it with DT_Posts::get_post($post_type, $post_id, true, false, true) (permissions skipped), copies location_grid into the row, and Disciple_Tools_Reports::insert() as the forged user_id. WordPress REST will not require a nonce because permission_callback is __return_true. User IDs are enumerable. Subscriber and unauthenticated visitors are equivalent here. Latest upstream 1.7 (and current master) still has this code.

  magic-link/magic-link.php:116-156,158-281,437-475

  Recommendation

  In permission_callback, instantiate DT_Magic_URL($this->root) and return $magic->verify_rest_endpoint_permissions_on_post($request) so the submitted public_key is resolved to a user_id and must match parts.post_id. Reject requests whose parts.root/type/meta_key do not match this app. In endpoint_log, require the target post_id to already be on that user's prayer list (dt_post_user_meta row) and do not call DT_Posts::get_post with check_permissions=false. Do not treat X-WP-Nonce as a substitute for the magic-key check.

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.