Workflows WP Registry grade D+. High-severity findings · 2 findingsWP RegistryHigh-severity findings · 2 findingsOpen the reportD+

High-severity findings.

Audited release

0.5.0

Findings

2

Worst severity

high

Content hash

206548aae74a37b022186e06… Copy

Findings

• high Unauthenticated REST disclosure of published workflows including Slack webhook URLs

  information_disclosure

  hm_workflow is registered public=false, publicly_queryable=false, capability_type=workflow (mapped to manage_options/manage_workflows), but show_in_rest=true with REST_Workflows_Controller. That controller only changes the namespace to workflows/v1 and then calls parent::register_routes(); it does not override get_items_permissions_check or check_read_permission. Core WP_REST_Posts_Controller::get_items_permissions_check returns true for context=view, and check_read_permission returns true for any post with status publish without consulting read_workflow. Enabled workflows are stored as published hm_workflow posts, so unauthenticated GET /wp-json/workflows/v1/workflows (and GET of a single id) returns them. register_rest_field exposes event, subject, message, recipients (including resolved user display names) and destinations. Slack destination data includes the incoming webhook URL, which is a write credential for the configured channel. Writes remain admin-gated via create/update/delete_item_permissions_check.

  inc/class-rest-workflows-controller.php:12-22

  Recommendation

  Override get_items_permissions_check, get_item_permissions_check, and check_read_permission to require current_user_can('edit_workflows') (or manage_options/manage_workflows). Do not treat published hm_workflow rows as publicly readable. Strip destination secrets (Slack incoming_webhook) from any response not in context=edit for a privileged user.

• high Unauthenticated IDOR of editorial (workflow) comments via core comments REST

  information_disclosure

  Editorial comments are stored as comment_type=workflow and are intended to be visible only to users who can edit the parent post (the plugin’s own /workflows/v1/comments controller correctly requires edit_post). Isolation is incomplete: comments_query() only adds type__not_in=workflow on WP_Comment_Query, and bails if type is already workflow. Core GET /wp-json/wp/v2/comments/{id} uses get_comment() (not that query) and WP_REST_Comments_Controller::check_read_permission treats any non-note approved comment on a readable post as public. The React UI always POSTs status=approved, and create_item() calls handle_status_param(), so these comments are approved. An unauthenticated client can enumerate sequential comment IDs and read editorial bodies, authors, and assignees meta on published posts. Users with edit_posts can also pass type=workflow on the collection route and list them. The dedicated workflows/v1/comments routes are not the leak.

  lib/events/new-editorial-comment.php:163-176

  Recommendation

  Reject unprivileged access to comment_type=workflow on core REST (rest_pre_dispatch or a rest_prepare_comment / get_item_permissions_check wrapper) unless current_user_can('edit_post', $comment->comment_post_ID). Do not short-circuit comments_query when type=workflow unless the request is the plugin’s own controller. Keep workflow comments unapproved or a non-public type if they must exist in the comments table.

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.