AI CRM Form WP Registry grade D+. High-severity findings · 3 findingsWP RegistryHigh-severity findings · 3 findingsOpen the reportD+

High-severity findings.

Audited release

1.5.0

Findings

3

Worst severity

high

Content hash

f1055d6b8456f3112a84ecd4… Copy

Findings

• high Unauthenticated GET /forms/{id} exposes CRM FormConfigIDs and full form rows

  information_disclosure

  register_rest_route GET /ai-crm-form/v1/forms/(?P<id>\d+) uses permission_callback __return_true. get_form() loads the entire wp_aicrmform_forms row (name, description, form_config including custom_css and messages, field_mapping, crm_form_id, status, timestamps) with no is_user_logged_in, current_user_can, nonce, or status==='active' check. IDs are sequential autoincrement, so GET /forms/1, /forms/2, … enumerates every form, including inactive ones the shortcode renderer refuses. crm_form_id is a FormConfigID-uuid that is not printed in the public [ai_crm_form] HTML (only internal form id and data-field-id FieldIDs appear). AICRMFORM_CRM_API::submit sends that FormConfigID as submission.form_id to a hardcoded production URL with Content-Type JSON and no Authorization header — the UUID is the only CRM credential. Observable: an unauthenticated client retrieves FormConfigID + FieldID map for a form that is not embedded anywhere (or is inactive), then POSTs leads straight to forms-prod.apigateway.co, bypassing WordPress logging and any later status gate. The frontend never calls this route (server-side shortcode render); admin preview/edit uses it with a nonce that is unnecessary given __return_true. Fix: use admin_permission_check (or at least require status=active and strip crm_form_id/field_mapping from any public schema), and do not return the raw DB row.

  includes/class-rest-api.php:73-82,392-414

  Recommendation

  Change GET /forms/{id} permission_callback to admin_permission_check (manage_options), matching GET /forms collection. If a public schema is required, return only active forms and a minimized field list (name, type, required, options) — never crm_form_id, field_mapping, or custom_css. Keep CRM credentials server-side.

• medium Public POST /submit/{id} ignores form status and returns CRM debug internals on failure

  information_disclosure

  POST /ai-crm-form/v1/submit/(?P<id>\d+) is permission_callback __return_true (expected for a public form) but submit_form() never checks $form->status === 'active' (the shortcode does). An unauthenticated POST with {data:{...}} against an inactive form still calls submit_with_mapping, $wpdb->insert into wp_aicrmform_submissions, and wp_remote_post to the CRM. On CRM failure it returns HTTP 400 JSON with debug.form_data, debug.field_mapping, debug.mapped_data, debug.crm_payload, debug.crm_form_id, debug.response_code, and debug.response_body (raw CRM error body). There is no rate limit, nonce requirement, or allow-list of field names (arbitrary keys in data are stored). Observable: POST /submit/1 with empty/invalid fields that the CRM rejects yields the same FormConfigID/mapping leak as GET /forms/{id}, plus the upstream CRM error; POST against a status=inactive form still creates a submissions row and a CRM lead. form.js displays result.data.error via textContent (not XSS). Fix: refuse inactive/missing forms with 404; strip the debug object from production responses; optionally require the wp_rest nonce already localized on the front end and validate data keys against form_config.fields.

  includes/class-rest-api.php:128-137,903-988

  Recommendation

  If ('active' !== $form->status) return 404. Remove debug from the public error response (log server-side under WP_DEBUG only). Validate submitted keys against the stored field list. Consider a nonce or captcha/rate-limit on the public route.

• low Every form submission error_log's PII and the full CRM payload

  debug_code

  submit_form() always error_log's form_id, crm_form_id, field_mapping, and the raw submitted form_data (names, emails, phones, messages). AICRMFORM_CRM_API::submit then error_log's the CRM URL and JSON payload; failures log the raw response_body. None of these are gated on WP_DEBUG. On hosts that write PHP logs to wp-content/debug.log or otherwise web-accessible files, lead PII and FormConfigIDs become recoverable. Observable: each public POST /submit/{id} appends respondent PII to the PHP error log; not a direct site takeover.

  includes/class-rest-api.php:942-949

  Recommendation

  Remove production error_log of form_data, CRM payloads, and FormConfigIDs. If support logging is needed, gate it behind WP_DEBUG and never print respondent PII.

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.