High-severity findings.

Audited release

1.0.2

Findings

2

Worst severity

high

Content hash

4e7c15b7a73851ea2b2ac9b0… Copy

Findings

• high Authenticated (manage_dt / D.T Admin) arbitrary update_option via REST /option

  missing_capability

  Disciple_Tools_Setup_Wizard_Endpoints registers POST /wp-json/disciple-tools-setup-wizard/v1/option with permission_callback has_permission(), which is only current_user_can('manage_dt'). option_set() sanitizes the key then passes the raw value to update_option() with no allowlist or denylist. Array values default to array_replace_recursive() merge into the existing option unless overwrite=true, so a caller can graft capabilities onto {prefix}user_roles. Disciple.Tools documents Manage D.T (dt_admin) as customizing DT settings/plugins and explicitly not Manage WP; the theme's own dt-admin-settings/update-dt-options skips any key that does not start with dt_. This plugin's sample config does set blogname/admin_email, but the endpoint also accepts users_can_register, default_role=administrator, siteurl, home, active_plugins, template/stylesheet, and {prefix}user_roles. Subscriber cannot call it. A D.T Admin (no manage_options) can. REST cookie auth still requires X-WP-Nonce, so this is not unauthenticated CSRF; it is a missing-authorization primitive relative to the capability the action requires.

  rest-api/rest-api.php:15-74,86-94

  Recommendation

  Keep permission_callback on manage_dt (or raise it to manage_options for WP-core keys). Allow-list option keys the wizard is meant to set (blogname, blogdescription, admin_email, dt_setup_wizard_config, dt_setup_wizard_progress, and other explicit dt_* keys). Reject users_can_register, default_role, siteurl, home, active_plugins, template, stylesheet, {prefix}user_roles, and any key the current user cannot change via current_user_can('manage_options'). Do not merge arbitrary arrays into existing options. Mirror the theme's strpos($option_key, 'dt_') !== 0 continue guard for DT-only writes.

• medium Stored admin XSS via innerHTML of wizard config slugs, option keys, and usernames

  xss_stored

  createMessageLi assigns attacker-influenced strings to li.innerHTML. showMessage is called with plugin['slug'], option.key, and user.username taken from dt_setup_wizard_config (written through option_set / the Settings JSON form by any manage_dt user) or from the Advanced JSON runner. PHP echoes those values through esc_html into hidden inputs; the browser HTML-decodes them, JSON.parse restores the original string, and innerHTML then parses markup. <script> tags would not run via innerHTML, but event-handler injection (<img src=x onerror=…>, <svg onload=…>) does. The page is wp-admin Setup Wizard, reachable by dt_admin and by WP administrators who also have manage_dt. A D.T Admin can plant the payload in the shared config and have it execute in a full administrator's session when that admin clicks Install, Update, or Add User. No frontend consumer.

  admin/js/wizard.js:387-409

  Recommendation

  Set textContent (or document.createTextNode) instead of innerHTML in createMessageLi. Treat config-derived slugs, keys, and usernames as untrusted even for manage_dt authors. If HTML is required, pass the string through a sanitizer that strips event handlers. Validate plugin slugs against ^[a-z0-9_-]+$ before render or install.

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.