High-severity findings.

Audited release

1.1.2

Findings

2

Worst severity

high

Content hash

10b7ce45a7ec54ffb53c4cd1… Copy

Findings

• high Unauthenticated AJAX truncates deploy history and pending-change tables

  missing_auth

  Deployeur_Ajax registers mkd_log_history and mkd_clear_history on both wp_ajax_ and wp_ajax_nopriv_. Neither handler checks a nonce, a capability, or is_user_logged_in(). mkd_clear_history always runs TRUNCATE TABLE {$wpdb->prefix}deployeur_history and returns success. mkd_log_history inserts $_POST['status'] and $_POST['webhooks'] into that table (user_id = get_current_user_id(), so 0 for anonymous callers); if status equals the string success it also TRUNCATEs {$wpdb->prefix}deployeur_update, which is the pending-changes queue the Dashboard renders. An unauthenticated POST to /wp-admin/admin-ajax.php therefore wipes the editor review list, wipes or forges the deploy audit log, and needs no CSRF token. The Logs/Dashboard screens (manage_options only) are the consumers: after the call they show an empty pending list and/or attacker-written history rows. This is not a cosmetic counter — it is the plugin's operational deploy queue.

  includes/class-deployeur-ajax.php:5-51

  Recommendation

  Drop the wp_ajax_nopriv_ registrations. In both handlers call check_ajax_referer() and current_user_can('manage_options') (or a dedicated deploy cap) before any write. Sanitize status to an allow-list (success|error) and do not take webhooks from the client — read deployeur_webhook_url from the option. Keep TRUNCATE of the pending-update table on the authenticated success path only.

• high Deploy webhook secret exposed in admin bar to every logged-in user

  information_disclosure

  add_admin_topbar_item hooks admin_bar_menu at priority 1000 with no capability check. For every user who can see the admin bar (WordPress default: all logged-in roles, including Subscriber and Customer, on front end and in wp-admin) it appends an unescaped meta['html'] span whose data-deploy-webhook attribute is get_option('deployeur_options')['deployeur_webhook_url'] — the Netlify/Vercel build hook, a secret that anyone can invoke to rebuild production. enqueue_scripts runs on admin_enqueue_scripts for every admin page with no hook-suffix or cap gate, so dist/index.js bind-clicks #trigger-deploy on Subscriber profile.php and fetch()es that URL (POST for Netlify, GET for Vercel) then calls mkd_log_history. Observable: view-source of any front-end page while logged in as Subscriber copies the hook; curling it publishes whatever is currently in WordPress (the plugin's whole point is to delay that publish) and consumes hosting build minutes. Settings UI itself is manage_options-only; the leak is the admin-bar HTML, not the settings form.

  admin/class-deployeur-admin.php:92-95,146-192

  Recommendation

  Gate add_admin_topbar_item and enqueue_scripts on current_user_can('manage_options') (or a dedicated deploy cap) and is_admin_bar_showing() for that cap. Do not put the webhook URL in HTML or JS; keep it server-side and trigger the hosting request from an authenticated, nonced admin-ajax/REST handler. Escape any remaining admin-bar attributes with esc_attr/esc_url.

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.