WowOptin < 1.4.38 – Unauthenticated Opt-in Deactivation and Template Row Injection | CVE 2026-14603

Description

The plugin does not have proper authorization on a REST endpoint, allowing unauthenticated users to disable all of the site's opt-in forms and insert new template-based opt-in rows into the database.

Proof of Concept

WowOptin registers the REST route GET /wp-json/optn/v1/recipes/<id> with permission_callback => '__return_true' (admin/class-rest-admin.php), so it is reachable with no authentication, nonce, or cookie. The handler forwards the query parameters to includes/class-db.php::activate_recipe(): when disable_others=1 it runs an unconditional UPDATE disabling every opt-in row, then inserts new rows from a vendor template whose enabled flag is taken from the status parameter.

Prerequisites (all default):
  - WowOptin <= 1.4.37 active.
  - At least one opt-in configured, so the mass-disable is observable.
  - The plugin's own template API (apps.wowoptin.com) reachable (default);
    recipe id 3 is a valid catalogue entry ("Morning Magazine").

Single unauthenticated request (no cookies, no nonce):

  curl 'https://victim.example/wp-json/optn/v1/recipes/3?disable_others=1&status=1'

Result:
  - HTTP 200. Every existing opt-in form on the site is set enabled=0
    (all lead-capture popups/forms stop rendering).
  - A new opt-in row from the vendor's "Morning Magazine" template is inserted
    with enabled=1 and begins rendering to site visitors.

Fixed in 1.4.38, which changes the permission_callback to the capability check
used by every sibling admin route (current_user_can(OPTN_MIN_CAPABILITY)); the
same request then returns HTTP 401 rest_forbidden.