Medium-severity findings.

Audited release

1.4.2

Findings

1

Worst severity

medium

Content hash

ca2c0b2f22a8145ac060fec0… Copy

Findings

• medium Subscriber+ REST revisions endpoint discloses full HTML, autosaves, and password-protected content

  information_disclosure

  register_rest_route( 'post-history/v1', '/revisions/(?P<id>\d+)' ) is a public GET once the route exists. REST\bootstrap() is attached from conditional_bootstrap() on init whenever should_enable() passes — that helper is only is_user_logged_in() plus “some post type supports hm-post-history”, which setup_post_types() grants to every type that already supports revisions (post and page by default). The widget does not have to be placed. revisions_request_permissions_callback then short-circuits: if get_post_status( $id ) === 'publish' it returns true with no current_user_can('read_post'), no current_user_can('edit_post'), and no post_password / post_password_required() check. Password-protected posts remain status publish, so their revision bodies (typically including the current protected content) are returned to a Subscriber who cannot see the post on the front end and cannot read it from core /wp/v2/posts. Non-publish posts fall through to edit_post; missing parents return true. get_revisions_query() is WP_Query( post_parent, post_type=revision, post_status=inherit ) with attacker-controlled per_page (absint, no max) and does not exclude autosaves (post_name {id}-autosave-v1), so in-progress unpublished edits of a published post are included. build_revisions_list() puts apply_filters( 'the_content', $revision->post_content ) plus the reviser's display_name into JSON. Core WP_REST_Revisions_Controller::get_items_permissions_check requires edit_post for this data. insert_server_side_settings() localizes a wp_rest nonce on every frontend page for logged-in users, so the Subscriber does not need the widget UI. Unauthenticated callers do not register the route on a default install. Consequence is confidentiality of revision HTML / protected bodies / autosaves, not RCE — hence medium, matching Subscriber+ revision/protected-content disclosure CVEs.

  inc/rest.php:32-60,71-83,93-109,143-166

  Recommendation

  Align with core revisions REST: require current_user_can( 'edit_post', $parent_id ) unless you truly intend public history, in which case still (1) deny when post_password is set unless the requester may read the post (current_user_can('read_post') or a valid password), (2) exclude autosaves (wp_is_post_autosave / post_name NOT LIKE '%-autosave-%'), (3) do not treat a missing parent as allowed, (4) cap per_page. Register the route unconditionally and put the real gate in permission_callback so login-only route registration is not the only unauth control. Do not localize the REST nonce on every page if the widget is absent.

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.