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

High-severity findings.

Audited release

1.1.1

Findings

2

Worst severity

high

Content hash

be00fc59e5f7af7b2c5e4aea… Copy

Findings

• high Unauthenticated deletion of form submissions and arbitrary post meta

  missing_auth

  delete_results and trash_result are hooked to init with no capability or nonce checks. delete_results runs when $_REQUEST['delete-results'] and $_REQUEST['form'] are present and calls delete_post_meta($form, 'form_result') (or delete_metadata_by_mid for date-filtered rows), wiping stored submissions for that form. trash_result runs when $_REQUEST['action']==='trash-result' and $_REQUEST['sent'] is set, then delete_metadata_by_mid('post', $_REQUEST['sent']) with no check that the row is form_result — any post meta ID on the site can be deleted (ACF fields, WooCommerce order meta, attachments, etc.) by iterating sent=1,2,3,... The admin UI posts these as GET (no nonce field); the template even uses action=trash-submission while the handler expects trash-result, so the button is broken, but the handler remains fully reachable. Observable: GET /?delete-results=1&form=<id> removes all form_result meta; GET /?action=trash-result&sent=<mid>&form=<id> removes that post-meta row and redirects.

  result-list.php:32-33,92-119

  Recommendation

  Require current_user_can('edit_pages') and check_admin_referer in both handlers; switch them to admin-post.php. Restrict trash_result to meta rows whose meta_key is form_result and whose post_id matches the given form. Add a real nonce to the submissions UI and fix the trash-submission vs trash-result action mismatch.

• high Unauthenticated stored XSS in the submissions admin table and notification emails

  xss_stored

  Successful public submit-form stores payload field values in post meta form_result (save_to_db defaults on) without sanitization. templates/result-list-page.php echoes $item[$field['name']] (and join of array values) into the wp-admin submissions table with no esc_html. File cells go through get_file_info (escaped); text/email/textarea/select/checkbox cells do not. An unauthenticated submitter can store <script> or event-handler HTML. Any user with edit_pages who opens Forms → Submissions executes it in their admin session (create-user / plugin-install ATO). The same raw values are echoed in templates/email-notification.php ($field['value']) and substituted into the HTML autoreply body via str_replace of {{field}} placeholders, so the site also sends attacker HTML from its From: address. Consumer is the initial HTML parse of the admin document (not innerHTML), so <script> runs.

  templates/result-list-page.php:108-112

  Recommendation

  Escape all submission values with esc_html() (or wp_kses_post only if HTML is intentionally allowed) in the admin table. Sanitize on save (sanitize_text_field / sanitize_email / wp_kses). Escape email bodies or send text/plain. Do not concatenate untrusted values into HTML mail templates.

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.