SEC.co
Emergency
HIGH 7.1

CVE-2026-49141: WACRM Multi-Tenant Authorization Bypass Vulnerability

WACRM contains an authorization flaw that allows someone with valid login credentials to view and change contact records from other customers. The vulnerability exists in the automation engine and doesn't properly verify that the attacker owns the contact they're modifying. An attacker needs only to know a contact's ID number to change things like names, email addresses, and company information across different customer accounts.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.1 HIGH · CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:H/A:N
Weaknesses (CWE)
CWE-639
Affected products
0 configuration(s)
Published / Modified
2026-06-08 / 2026-07-14

NVD description (verbatim)

WACRM prior to commit 73041bf contain an authorization bypass vulnerability in the automation engine that allows authenticated attackers to access and modify contacts belonging to other tenants by supplying an arbitrary caller-controlled contact_id in the POST request body without tenant ownership verification. Attackers can exploit the service-role client that bypasses row-level security to modify victim contact fields including name, email, and company across tenant boundaries using only a known contact UUID.

3 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The vulnerability is a multi-tenant authorization bypass in WACRM's automation engine (CWE-639: Authorization through User-Controlled Key). When processing POST requests to modify contacts, the application accepts a caller-supplied contact_id parameter without validating tenant ownership. The vulnerability stems from improper use of a service-role client that bypasses row-level security controls, enabling modification of contact attributes (name, email, company) across tenant boundaries using only knowledge of the target contact UUID. The flaw affects versions prior to commit 73041bf.

Business impact

Customer data isolation is compromised in multi-tenant deployments. An authenticated attacker could systematically enumerate and corrupt contact records belonging to other organizations, causing business disruption, data integrity violations, and potential compliance violations depending on regulatory scope. This is particularly concerning for WACRM deployments hosting competitive or sensitive business relationships, as attackers could alter contact information or gather intelligence on other tenants' customer bases.

Affected systems

WACRM versions prior to commit 73041bf are affected. The vulnerability requires an authenticated user account but does not require administrative privileges. Any user with login credentials can exploit the flaw to access and modify contacts outside their tenant boundaries.

Exploitability

Exploitation requires valid authentication credentials (PR:L) and knowledge of target contact UUIDs. While the vulnerability is network-accessible and requires no user interaction, the CVSS score of 7.1 reflects the medium complexity (AC:H) involved in discovering valid contact IDs across tenants. The attack scope is changed (S:C), meaning an authenticated user in one tenant can impact resources in other tenants. No zero-day exploitation in the wild has been reported; this is not tracked in CISA's Known Exploited Vulnerabilities catalog.

Remediation

Upgrade WACRM to a version incorporating commit 73041bf or later, which implements proper tenant ownership verification in the automation engine. All modifications to contact records must validate that the authenticated user's tenant owns the contact before allowing any changes. Implement row-level security at the application layer rather than relying on service-role clients that bypass these protections.

Patch guidance

Apply the patch corresponding to commit 73041bf or any subsequent release. Verify the fix by confirming that contact modification requests are now rejected when the authenticated user's tenant does not own the target contact. Test across multiple tenant instances to ensure isolation is properly enforced. Organizations should prioritize patching based on the exposure of their WACRM deployment to untrusted authenticated users.

Detection guidance

Monitor POST requests to contact modification endpoints for patterns indicating tenant boundary violations. Look for repeated attempts to modify contact_id values with mismatched tenant ownership. Enable audit logging on all contact record changes and review logs for modifications made by users to contacts outside their tenant. If available, enable database-level tenant validation alerts. Review authentication logs to identify compromised or shared credentials that could enable this attack.

Why prioritize this

This vulnerability merits prompt attention because it directly violates multi-tenant data isolation, a critical security property of SaaS systems. The combination of high integrity impact (I:H) with changed attack scope (S:C) means a single compromised user account could corrupt data across multiple customer organizations. Although the CVSS score is 7.1 (HIGH), the business severity is elevated because customer data integrity and isolation are foundational to SaaS trust.

Risk score, explained

CVSS 3.1 score of 7.1 reflects: (1) network accessibility and low privilege requirements that increase likelihood of exploitation by insiders or via credential compromise; (2) medium attack complexity from the need to discover valid contact UUIDs; (3) high integrity impact due to ability to modify contact attributes; (4) changed scope because one tenant's user impacts another tenant's data; (5) low confidentiality impact as this is primarily a modification, not data exfiltration attack. The score does not capture the business-critical nature of multi-tenant isolation violations.

Frequently asked questions

Can an attacker modify contacts if they don't know the exact contact UUID?

The vulnerability requires knowledge of a valid contact UUID to target a specific contact. However, UUIDs can sometimes be enumerated through information disclosure or inferred from contact listing endpoints. Additionally, attackers might systematically probe common UUID patterns. Defenders should assume that if UUIDs are somewhat predictable or discoverable, they can be exploited.

Does this affect WACRM deployments where users are strictly isolated by role?

Yes. The vulnerability exists at the API layer and bypasses row-level security controls, so role-based access controls alone do not prevent it. The service-role client mechanism used in the automation engine creates a privileged pathway that circumvents tenant checks. All deployments using the affected code are vulnerable regardless of additional role-based policies.

What should we do if we've detected suspicious contact modifications?

Immediately review audit logs to identify which user accounts made cross-tenant modifications and when. Rotate credentials for any accounts that appear to have been misused. Review and restore contact data from backups if modifications affected important customer records. Notify any other WACRM tenants if your investigation reveals that attackers may have accessed their contacts.

Is this vulnerability being exploited in the wild?

As of the published date, this vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog and has no confirmed active exploitation. However, the low barrier to entry for authenticated users means the risk of exploitation increases with each passing day without patching.

This analysis is based on vulnerability disclosure data current as of July 2026. WACRM version numbers and patch commit references should be verified directly with the vendor advisory. No exploit code or weaponized proof-of-concept is provided. Organizations should conduct internal testing before deploying patches to production environments. This vulnerability requires authenticated access; the impact is limited to systems where untrusted users have valid credentials or where credential compromise is plausible. Source: NVD (public-domain), retrieved 2026-07-16. Analysis generated by SEC.co (claude-haiku-4-5).

Weaknesses (CWE)

CWE-639

Related vulnerabilities