WACRM CVE-2026-77240

Requires an authenticated account of any privilege level (a 'viewer' member is sufficient) on a self-hosted WACRM instance at version 0.7.0 or earlier; no admin rights, no user interaction, and no non-default configuration are needed since the flawed RLS policy and the authenticated GRANT on the SECURITY DEFINER RPCs ship by default. Exploitation is performed by calling the Supabase/PostgREST REST API directly (PATCH /rest/v1/profiles or POST /rest/v1/rpc/match_ai_knowledge_fts) with attacker-chosen account_role/account_id/p_account_id values. The only real limiting factors are that the attacker must first obtain a valid low-privilege JWT/account on the target instance and that the product itself is rarely deployed.

This is a genuine high-priority authorization flaw, not merely an inflated CVSS number. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 9.9) is well-supported by the source-code evidence: the fix PR #350 documents that any 'authenticated' PostgREST client can issue a single UPDATE on the profiles table to self-promote to 'owner' or relocate into a victim tenant, and can call SECURITY DEFINER RPCs with a foreign p_account_id to read another tenant's knowledge base. Only PR:L is required (any registered viewer), attack complexity is low, and no user interaction is needed. The scope change (S:C) is defensible because a low-privileged member crosses the tenant/security boundary to reach resources of a different security authority. Missing/soft signals temper urgency: there is NO EPSS score, NO CISA KEV listing, and NO standalone weaponized exploit in the input - although the advisory (GHSA-fg5p-2qc3-jmxr) and PR literally document the exact request payloads, which materially lowers the bar for exploitation. The dominant mitigating factor is deployment footprint: WACRM is an obscure self-hostable template, so real-world exposure is small despite the near-maximal severity. Net: treat as critical-to-patch for any operator actually running WACRM ≤0.7.0, but its aggregate internet risk is limited by rarity rather than by technical difficulty.

An attacker registers or is invited as a low-privilege 'viewer' on a self-hosted WACRM instance, then sends a direct PostgREST PATCH to /rest/v1/profiles setting account_role='owner' (or account_id to a victim tenant's UUID), passing the RLS WITH CHECK because user_id is unchanged. With owner rights or a switched tenant they read and modify other tenants' CRM data; separately they POST to /rest/v1/rpc/match_ai_knowledge_fts with a foreign p_account_id to exfiltrate another tenant's knowledge base. No standalone exploit tool is published, but the security advisory and fix PR document the exact exploit queries.