CVE-2026-77240 in Wacrm
Summary
by MITRE • 09/18/2026
WACRM is a self-hostable CRM template for WhatsApp. In version 0.7.0 and earlier, the profiles_update row-level security policy in supabase/migrations/017_account_sharing.sql permits authenticated users to modify their own account_role and account_id, allowing a viewer to self-promote or move into another tenant and then access or modify tenant resources. Separately, match_ai_knowledge_fts and match_ai_knowledge_semantic in supabase/migrations/030_ai_knowledge.sql run as SECURITY DEFINER, accept a caller-controlled p_account_id, and omit an is_account_member check, allowing an authenticated non-member to read another tenant's knowledge-base chunks. This vulnerability is fixed with commit e01f7ed37184f972ace8fb2da5c3e37e56a6050f.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability in WACRM versions 0.7.0 and earlier stems from insufficient access control mechanisms within the Supabase database layer, specifically affecting row-level security policies and stored procedure definitions. The application relies on a multi-tenant architecture where distinct customer data must remain isolated. However, flaws in the migration scripts responsible for account management and AI knowledge retrieval allow authenticated users to bypass these isolation boundaries. This results in both privilege escalation within a tenant and unauthorized cross-tenant data access, fundamentally compromising the integrity and confidentiality of the system's data model.
The first critical flaw resides in the profiles_update row-level security policy defined in supabase/migrations/017_account_sharing.sql. Row-level security is designed to restrict database operations based on user context, but this specific implementation permits authenticated users to modify their own account_role and account_id fields during profile updates. By manipulating these attributes, an attacker with viewer privileges can self-promote to a higher privilege level or alter their account_id to match that of another tenant. This action effectively allows the attacker to impersonate other users or tenants within the system. Once elevated permissions are achieved through this manipulation, the attacker gains unrestricted access to modify and view resources belonging to the targeted tenant, leading to a complete breakdown of multi-tenant isolation.
The second vulnerability involves two functions, match_ai_knowledge_fts and match_ai_knowledge_semantic, located in supabase/migrations/030_ai_knowledge.sql. These functions are defined with SECURITY DEFINER privileges, meaning they execute with the permissions of the function owner rather than the calling user. While this is a common pattern for enforcing business logic, it requires rigorous internal checks to ensure security boundaries are maintained. In this case, both functions accept a caller-controlled parameter p_account_id but fail to perform an is_account_member check before processing requests. Consequently, any authenticated user can invoke these functions and specify the account ID of another tenant. Since there is no verification that the calling user belongs to the specified account, non-members are able to retrieve knowledge-base chunks belonging to other tenants. This represents a direct violation of data confidentiality across organizational boundaries.
The operational impact of these vulnerabilities is severe for organizations using WACRM as their customer relationship management solution. The ability to self-promote or hijack tenant identities allows attackers to escalate privileges, leading to unauthorized modifications of business-critical CRM data. Furthermore, the cross-tenant access to AI knowledge bases exposes sensitive proprietary information, such as internal documentation, training materials, and client-specific insights, to competitors or malicious actors. This compromises not only individual user privacy but also enterprise-level security postures, potentially violating regulatory requirements regarding data isolation and confidentiality in multi-tenant SaaS environments.
These issues align with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization for the privilege escalation aspect, while the cross-tenant access corresponds to CWE-200 Exposure of Sensitive Information to an Unauthorized Actor and CWE-771 Missing Reference to Active Allocated Resource in some contexts. In terms of MITRE ATT&CK frameworks, these vulnerabilities facilitate techniques related to Privilege Escalation (T1068) and Collection from Remote Application Servers (T1213), as well as potential Lateral Movement if the compromised credentials are used to access other systems within an organization's infrastructure.
The vulnerability has been addressed in commit e01f7ed37184f972ace8fb2da5c3e37e56a6050f, which likely introduces stricter validation checks and removes the ability for users to modify critical identity fields through profile updates. To mitigate similar risks, developers should ensure that row-level security policies strictly limit write access to only non-sensitive attributes or enforce strict ownership verification before any modifications are allowed. Additionally, functions operating with SECURITY DEFINER privileges must always validate tenant membership using explicit checks against a central authorization table rather than relying solely on the caller's session context. Regular audits of database migration scripts and automated testing for multi-tenant isolation boundaries are recommended to prevent recurrence of such architectural flaws.