[Security] IDOR in MCP tools/call endpoint (get-entry/delete-entry) allows cross-user entry disclosure and deletion — CVE-2026-89101 #1665

Summary

CVE-2026-89101 — CVSS 6.5 (Medium), Authorization Bypass Through User-Controlled Key (CWE-639)

Everest Forms ≤ 3.6.1 is vulnerable to an Insecure Direct Object Reference via the MCP /tools/call JSON-RPC endpoint (POST /wp-json/everest-forms/v1/mcp). Authenticated users with own-scoped only custom capabilities (everest_forms_view_entries, everest_forms_delete_entries, etc., granted without the matching "Others" capabilities via Everest Forms → Tools → Roles and Permission) can view and permanently delete form entries — including PII — belonging to any other user, regardless of form ownership.

• Reported: September 10, 2026 via vulnerability disclosure portal
• Researcher: Trgomez
• Affected versions: All versions up to and including 3.6.1
• Patched: No (as of report date)

Root Cause

In includes/abilities/class-evf-abilities-handlers.php, the can_view_entries() / can_delete_entries() checks call current_user_can('everest_forms_view_entries') / current_user_can('everest_forms_delete_entries') as global primitive capability checks with no object id.

Because no object id is passed to current_user_can(), WordPress's map_meta_cap filter (EVF_Install::filter_map_meta_cap) — which is what normally resolves "own" vs. "others" ownership — never runs. As a result, get-entry and delete-entry operate on any entry_id the caller supplies/guesses, with no ownership check at all.

This differs from other parts of the plugin (e.g. create_entry()) which already use the correct per-object meta-cap pattern.

Impact

An authenticated user with only "own"-scoped capabilities (not manage_everest_forms, no "Others" caps) can, via the MCP endpoint:

1. Enumerate/guess entry_id values and call get-entry to read another user's form entries, including PII submitted through public contact/lead forms.
2. Call delete-entry to permanently delete another user's entries.

Proof of Concept (summary)

A PoC script was provided by the researcher demonstrating:

• Login as a low-privilege user granted only own-scoped everest_forms_view_entries / everest_forms_delete_entries (no "Others" caps, no manage_everest_forms).
• Unauthenticated requests to the MCP endpoint are rejected; only login is required beyond that (no per-object authorization).
• list-forms + get-entry (brute-forcing entry_id 1–20) successfully disclosed a foreign entry's field values.
• delete-entry on a foreign entry succeeded, confirmed by a subsequent get-entry returning "not found."

Full PoC script is attached to the original vulnerability report in the disclosure portal (not reproduced here) — check the security tracker for the full script if needed for verification/regression testing.

Recommended Fix (per Threat Intelligence Team)

Replace the global primitive-cap checks in EVF_Abilities_Handlers with the per-object meta-cap checks the plugin already uses elsewhere (e.g. in create_entry()):

• Resolve the target form_id at the handler level and call:
  • current_user_can('everest_forms_view_form_entries', $form_id)
  • current_user_can('everest_forms_edit_form_entries', $form_id)
  • current_user_can('everest_forms_delete_form_entries', $form_id)
  • current_user_can('everest_forms_view_form', $form_id)
  • etc.
• For list-forms and analytics-summary, scope the query by author (post_author = get_current_user_id()) unless the caller holds the "others" capability or manage_everest_forms.
• Reject requests whose supplied entry_id/form_id belongs to a form the caller does not own, when the caller only holds own-scoped capabilities.

Checklist

• Patch can_view_entries() / can_delete_entries() (and equivalent handlers) to use per-object meta-cap checks
• Scope list-forms / analytics-summary by author unless "others" cap or manage_everest_forms is held
• Add regression test covering own-scoped-only role attempting cross-user get-entry / delete-entry
• Confirm fix against the researcher's PoC
• Coordinate disclosure timeline / changelog entry referencing CVE-2026-89101