Medium-severity findings.

Audited release

1.5.2

Findings

2

Worst severity

medium

Content hash

a62a8245bb679ca605ebffe2… Copy

Findings

• medium Unauthenticated REST widget query renders non-public posts via get_post() with no permission_callback

  information_disclosure

  conductor/v1/widget/query/{number} is registered for GET and POST with no permission_callback, so WordPress treats it as public. The route is on by default (Conductor_Options rest.enabled defaults true). widget_query loads the Conductor Widget instance by number from get_settings() (all instances, including inactive sidebars), requires only is_rest_api_enabled() (widget rest.enabled defaults true), then widget_rest() renders HTML. For feature-one widgets, Conductor_Widget_Default_Query::query() calls get_post($instance['post_id']) with no post_status / is_post_publicly_viewable() / current_user_can('read_post') check, then get_content_by_id() runs the_content on that post. WP_Query 'many' mode still defaults to publish, but a single-post widget that once pointed at a published piece which was later set private/draft/future continues to expose full content to uid 0. Widget numbers are sequential integers and are enumerable. Front-end AJAX pagination inserts the JSON HTML via jQuery.html(). This is not RCE and does not let an attacker pick an arbitrary post ID from the request; blast radius is every REST-enabled Conductor widget instance on the site.

  includes/class-conductor-rest-api.php:84-175

  Recommendation

  Add an explicit permission_callback (at least a public callback that still refuses widgets whose featured post is not is_post_publicly_viewable() for the current user). In Conductor_Widget_Default_Query::query(), replace bare get_post() with a readability check (post_status publish and empty post_password, or current_user_can('read_post', $id)) and skip rendering otherwise. Do not REST-enable widgets that are not assigned to a public sidebar. Consider defaulting rest.enabled to false.

• medium Add-ons page and EDD updater disable TLS verification and trust remote bodies (admin XSS and object injection)

  insecure_config

  Conductor_Admin_Add_Ons::maybe_fetch_add_ons_list() wp_remote_post()s https://conductorplugin.com/edd-api/products/ with sslverify false, sending the site license key, a JSON list of every installed plugin (including activate/deactivate nonce URLs), and freshly created add-on install nonces. display_add_ons_list() then echo's the raw response body into wp-admin with no wp_kses. The same host is queried by Conductor_Plugin_Updater::api_request() (also sslverify false); if sections is a serialized string it is passed to maybe_unserialize(). Because certificate verification is off, an on-path attacker between the WordPress host and conductorplugin.com can (1) inject script into the Add-Ons screen and take over the administrator session and (2) supply PHP object graphs to unserialize during admin_init update checks. This is not reachable by a Subscriber; it requires intercepting the server's outbound HTTPS. Install/activate AJAX handlers still require install_plugins/activate_plugins plus a nonce, so they are not a subscriber BAC issue.

  includes/admin/class-conductor-admin-add-ons.php:574-607

  Recommendation

  Set sslverify true on all conductorplugin.com requests. Pass the add-ons HTML through wp_kses_post (or a tight allowlist) before echo. Stop sending activate/deactivate nonce URLs and license keys in the clear to the add-ons feed; generate nonces locally after render. Replace maybe_unserialize() on API sections with JSON-only decoding (or unserialize with allowed_classes => false).

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.