CVE-2026-77239 in Wacrm
Summary
by MITRE • 09/18/2026
WACRM is a self-hostable CRM template for WhatsApp. In version 0.7.0 and earlier, WACRM flow and automation write routes authenticate account viewers but do not enforce the agent role before using a service-role database client that bypasses row-level security. In src/app/api/flows/[id]/route.ts, src/app/api/flows/[id]/activate/route.ts, and src/app/api/flows/route.ts, a viewer can create, edit, activate, or delete flows because membership-only checks are followed by service-role writes. In src/app/api/automations/route.ts and src/app/api/automations/engine/route.ts, a viewer can create active automations and trigger outbound WhatsApp actions without the role required by the underlying write policies. This can permit unauthorized workflow changes, destructive flow deletion, and outbound actions from a role intended to be read-only. This vulnerability is fixed with commit 03e851bea56dcf6bb21ff1b80ba531372bf3269f.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in WACRM versions 0.7.0 and earlier represents a critical authorization failure within the application's flow and automation management subsystems, specifically affecting self-hosted deployments of this WhatsApp CRM template. The core issue stems from an inconsistent implementation of role-based access control where authentication checks are performed but subsequent authorization logic fails to enforce strict role boundaries before executing privileged database operations. This architectural flaw allows users with viewer-level permissions, who should theoretically possess only read-only capabilities, to perform destructive and administrative actions that bypass intended security constraints. The vulnerability is rooted in the application's reliance on service-role database clients for write operations without verifying that the authenticated user holds the necessary agent or administrator privileges required by those specific endpoints.
In the flow management components located at src/app/api/flows/[id]/route.ts, src/app/api/flows/[id]/activate/route.ts, and src/app/api/flows/route.ts, the application logic first validates that a user is an authenticated viewer of the account but then proceeds to execute database writes using a service-role client. This sequence creates a privilege escalation vector because the service-role client typically possesses elevated permissions that override row-level security policies defined at the database level. Consequently, a viewer can create new flows, edit existing ones, activate dormant workflows, or delete active configurations without possessing the agent role required by the underlying write policies. This lack of intermediate authorization checks effectively neutralizes the intended separation between read-only viewers and operational agents, allowing unauthorized modifications to critical business logic within the CRM system.
Similarly, the automation subsystem exhibits identical flaws in src/app/api/automations/route.ts and src/app/api/automations/engine/route.ts. Here, a viewer can create active automations and trigger outbound WhatsApp actions despite lacking the requisite role permissions. The engine route is particularly dangerous as it allows for the execution of external communications, meaning an unauthorized user could potentially send messages or initiate workflows on behalf of the organization without detection by standard access controls. This capability transforms a simple information disclosure risk into a significant operational integrity threat, enabling malicious insiders or compromised viewer accounts to disrupt business operations, spam contacts, or exfiltrate data through automated channels that are supposed to be restricted to authorized agents only.
From a technical classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization, as the application fails to enforce proper access control policies for critical functions. The exploitation of service-role clients to bypass row-level security also relates to CWE-732 Incorrect Permission Assignment for Critical Resource, where the resource permissions are not correctly assigned based on the user's actual role rather than their authentication status. In terms of offensive cybersecurity frameworks such as MITRE ATT&CK, this behavior facilitates lateral movement and privilege escalation within the application layer, allowing an attacker with low-level access to achieve high-impact outcomes like data manipulation or unauthorized communication execution. The attack vector is primarily local if the CRM is self-hosted on a trusted network but becomes remote exploitable if exposed to untrusted networks without additional web application firewall protections.
The operational impact of this vulnerability extends beyond simple unauthorized edits, as it compromises the integrity and confidentiality of customer relationship data managed by WACRM. Attackers can delete critical flow configurations that drive sales or support processes, leading to service disruption for the organization. Furthermore, the ability to trigger outbound WhatsApp actions from a viewer account poses severe reputational risks if used to send spam or phishing messages using the organization's verified business identity. Since these actions bypass standard audit trails associated with agent-level activities, detecting such malicious behavior becomes significantly more difficult for security teams relying on role-based logs. The lack of enforcement means that any user granted view access can effectively act as an administrator regarding workflow and automation states, undermining the principle of least privilege fundamental to secure software design.
This vulnerability was addressed in commit 03e851bea56dcf6bb21ff1b80ba531372bf3269f, which presumably introduces explicit role checks before invoking service-role database clients or restricts the use of elevated privilege contexts to only those endpoints where such permissions are strictly necessary and verified. For organizations currently running WACRM version 0.7.0 or earlier, immediate mitigation involves upgrading to a patched version that enforces consistent authorization logic across all API routes. Until an upgrade is feasible, administrators should restrict network access to the self-hosted instance using firewalls or reverse proxies, ensuring that only trusted IP addresses can reach these endpoints. Additionally, implementing strict input validation and enhancing logging for flow and automation changes can help detect any unauthorized activity resulting from this flaw while a permanent fix is deployed. Regular security audits focusing on role-based access control implementations are recommended to prevent similar privilege escalation vectors in future development cycles.