Cross-tenant authorization bypass in Sage AR Automation API

Cash Collect có lỗ hổng ủy quyền không đúng trong Sage AR Automation API. Các kiểm tra ủy quyền ở cấp tenant không đầy đủ cho phép người dùng đã xác thực truy cập các tài nguyên quản trị thuộc tenant khác bằng cách chỉ định một mã định danh tenant hợp lệ nhưng khó dự đoán.

• Sage AR Automation: versions with a value less than June-R1-2026 are marked affected under the record's custom version scheme; the default status is unaffected.
• June-R1-2026 is the release boundary named in the affected data. The record does not independently verify every later or parallel release branch.

The vulnerability is in tenant-level authorization within the Sage AR Automation API. An authenticated user can send a network request containing a valid but non-predictable tenant identifier; the API does not sufficiently verify that the requested tenant is within the user's authorized scope. This is an Insecure Direct Object Reference condition, classified as CWE-639, where a user-controlled key selects resources belonging to another tenant. The record indicates that exploitation requires a low-privileged account, no user interaction, and high attack complexity. The specific endpoint, administrative resource types, and method of obtaining the tenant identifier are not disclosed.

The vulnerability is reachable over the network by an authenticated user with low privileges. The record indicates that no other user's interaction is required, but the attack has high complexity and requires a valid, non-predictable tenant identifier. The record does not confirm actual exploitation. No public exploit is identified in the supplied data, while known exploited status is unspecified; this should not be treated as proof that exploitation has never occurred.

The technical outcome is that an authenticated user can bypass tenant scoping and access administrative resources belonging to another tenant. Although the starting privilege is low, the flaw can cross the tenant boundary and affect resources belonging to other customers in the same service. The impact data indicates high potential effects on confidentiality, integrity, and availability, but does not specify which operations the API permits on the affected resources. Because the endpoint and resource types are unknown, it cannot be concluded that every administrative resource or every operation is affected.

The flaw breaks tenant isolation within the shared service. A valid low-privileged account may reach administrative resources belonging to another tenant, creating a risk of unauthorized disclosure or changes. The impact data indicates high potential effects on the confidentiality, integrity, and availability of affected resources. If those resources support write or administrative operations, operational effects could extend to an unrelated tenant; the record does not confirm a specific compromise scenario.

1. Inventory Sage AR Automation deployments and identify systems running a version less than June-R1-2026.
2. Move affected deployments to the June-R1-2026 release boundary identified in the affected data. Do not infer the status of unverified parallel branches.
3. After updating, verify authorization with a controlled test that confirms an account in one tenant cannot access another tenant's administrative resources merely by changing the tenant identifier.
4. If updating is not immediately possible, contact Sage for a supported mitigation. The record provides no specific temporary workaround, so unsupported compensating changes should not be assumed effective.

• Inventory Sage AR Automation deployments and identify their release versions using the product's custom release convention.
• Review Sage AR Automation API audit records, where available, for both the authenticated user's tenant and the tenant named in the request.
• Prioritize requests in which an authenticated user accessed administrative resources for a tenant other than the tenant assigned to that account.
• Review reads or changes to cross-tenant administrative resources performed by low-privileged accounts, but do not treat missing log evidence as proof of safety.
• The record does not define an endpoint, log field, or specific indicator; map these checks to the telemetry available in the deployment.