CVE-2026-85389 in Worklenz
Summary
by MITRE • 09/03/2026
Worklenz before 3.0.0 fails to verify task ownership by organization when resolving task-scoped API endpoints, allowing authenticated users to access another tenant's task data. Attackers can query task endpoints with arbitrary task UUIDs to retrieve work logs, comments, attachments, and project insights belonging to other organizations.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified in Worklenz versions prior to 3.0.0 represents a critical failure in server-side access control mechanisms, specifically within the context of multi-tenant SaaS architectures. The core technical flaw lies in the application's logic for resolving task-scoped API endpoints, where the system fails to verify that the authenticated user requesting data actually belongs to the same organization as the target resource. Instead of validating the relationship between the current session's tenant identifier and the organizational context associated with the requested Task UUID, the software relies solely on the presence of a valid authentication token. This oversight allows any authenticated account to bypass logical access restrictions by simply supplying arbitrary task identifiers in API requests. The absence of proper authorization checks means that the application treats all tasks as publicly accessible within the scope of an authenticated session, regardless of their actual ownership or privacy settings.
From an operational perspective, this vulnerability enables a severe breach of data confidentiality and integrity across organizational boundaries. An attacker with valid credentials for one organization can systematically enumerate task UUIDs to access sensitive information belonging to other tenants on the same platform. The impact extends beyond simple metadata exposure; attackers can retrieve detailed work logs that may contain proprietary process insights, read internal comments that could reveal strategic plans or personnel issues, and download attachments such as confidential documents, designs, or financial records. This capability effectively nullifies the isolation guarantees expected in a multi-tenant environment, allowing for cross-tenant data exfiltration without requiring privilege escalation or initial access to other accounts beyond basic authentication.
This flaw is technically classified under CWE-284 Improper Access Control and more specifically aligns with CWE-639 Authorization Bypass Through User-Controlled Key, as the attacker leverages a user-controlled input (the task UUID) to bypass authorization checks that should be enforced by the server based on tenant context. In terms of offensive security frameworks, this behavior corresponds directly to MITRE ATT&CK technique T1530 Data from Cloud Storage and potentially T1078 Valid Accounts if the attacker uses stolen credentials. The vulnerability highlights a common pitfall in web application development where developers assume that authentication implies authorization or fail to implement robust object-level permission checks for every API endpoint, particularly those handling sensitive business logic like task management systems.
To mitigate this risk, immediate remediation requires implementing strict server-side validation of tenant ownership for all resource requests. Developers must ensure that every API call involving a specific entity, such as a Task, verifies that the authenticated user's organization ID matches the organization ID associated with that entity before returning any data or performing actions. This should be enforced at the framework level through middleware or decorators to prevent individual endpoint oversights. Additionally, implementing rate limiting and anomaly detection on task-related API endpoints can help identify automated enumeration attempts by attackers probing for valid UUIDs across different tenants. Regular security audits focusing on logical access control flaws are essential to ensure that multi-tenant isolation remains intact as the application evolves.