Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-03T19:17:30.553Z",
  "pubdate": "2026-09-03T19:17:30.553Z",
  "executiveSummary": "Worklenz versions prior to 3.0.0 contain a critical Broken Access Control vulnerability categorized as an Insecure Direct Object Reference (IDOR).\nThe vulnerability resides in the application's task-scoped API endpoints, which fail to cryptographically or logically validate that a requester possesses authorization for a specific resource within their organization context.\nBy manipulating task UUIDs, an authenticated user can bypass multi-tenancy logical boundaries to access unauthorized data belonging to other organizations.\nThis flaw enables unauthorized disclosure of sensitive project management data, including work logs, project-specific comments, proprietary attachments, and internal project insights.\nThe attack requires valid user authentication within the Worklenz platform, but does not require administrative privileges, as the lack of server-side ownership verification permits lateral movement between organizational silos.\nThe impact is significant, as it leads to a complete breach of data confidentiality between supposedly isolated tenants.",
  "technicalDetails": "The root cause of this vulnerability is a failure in the server-side access control logic responsible for validating organizational ownership of requested resources. Specifically, the API endpoints tasked with retrieving task-scoped information perform a look-up based solely on the provided task UUID without verifying the requester's membership or assigned role within the associated organization.\nIn a secure multi-tenant architecture, the application should derive the permitted scope from the user's session context and correlate it with the resource's owner ID at the database or application layer. In Worklenz before 3.0.0, the backend retrieves and returns the requested object based exclusively on the UUID parameter supplied in the API request, effectively ignoring the security boundary between distinct tenants.\nThe attack flow proceeds as follows: First, an authenticated attacker identifies a valid task-scoped API endpoint. Second, the attacker discovers or guesses a target UUID—potentially through sequential identifier analysis or by capturing traffic from other instances. Third, the attacker submits a standard GET or POST request to the API, injecting the target task UUID into the endpoint path or body. Because the backend application logic omits an 'owner_id' check against the session's 'org_id', the server processes the request as a legitimate query and serves the unauthorized resource data back to the requester.\nThis vulnerability exposes diverse object types associated with the task, including granular work logs, communication threads (comments), uploaded files (attachments), and high-level analytical insights. The lack of per-request authorization checks renders the multi-tenancy model ineffective, as any user within the Worklenz ecosystem can access resources across the entire product installation, provided they have access to the target UUIDs. This exposure allows for large-scale data exfiltration and intellectual property theft by malicious actors capable of programmatic enumeration of task identifiers."
}