Description

Label Studio does not scope the annotation detail endpoint to the requesting user's organization. AnnotationAPI in label_studio/tasks/api.py declares queryset = Annotation.objects.all() and provides no get_queryset override, so the default lookup retrieves any annotation by primary key. The view's permission_required entries name annotations.view, annotations.change and annotations.delete, and label_studio/core/permissions.py registers every permission with rules.is_authenticated, so the check is satisfied by any logged-in account and no object-level organization test runs. The sibling task endpoint does constrain its queryset with project__organization set to the requester's active organization, which is the boundary this path omits. Annotation identifiers are sequential integers, so an authenticated user of one organization can enumerate identifiers to read, modify and delete annotations belonging to other organizations on the same instance. The same unscoped queryset appears on AnnotationConvertAPI in the same file.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-24T18:17:21.410Z",
  "pubdate": "2026-08-24T18:17:21.410Z",
  "executiveSummary": "An Insecure Direct Object Reference (IDOR) vulnerability exists in Label Studio within the annotation detail endpoint located in label_studio/tasks/api.py. The vulnerability arises due to a failure in scoping the annotation queryset to the requesting user's organization, allowing any authenticated user to access, modify, and delete arbitrary annotations across different organizations hosted on the same instance.\nThe impact of this security flaw includes unauthorized data access, data tampering, and data destruction, compromising the confidentiality, integrity, and availability of sensitive annotation data belonging to distinct tenants or organizations. Attackers require authentication to the platform, but no specialized privileges or object-level ownership are enforced beyond a generic authenticated session.\nExploitation is facilitated by the sequential integer nature of annotation identifiers, enabling trivial enumeration of resources. The risk implications are severe for multi-tenant deployments where strict data segregation between organizations is mandatory.",
  "technicalDetails": "The root cause of the vulnerability resides in label_studio/tasks/api.py, specifically within the AnnotationAPI and AnnotationConvertAPI classes. These views declare an unscoped queryset using queryset = Annotation.objects.all() without providing a get_queryset override to enforce multi-tenant boundaries.\nUnlike the sibling task endpoint, which properly constrains its queryset using project__organization set to the requester's active organization, the vulnerable annotation endpoints omit this critical security check. Access control relies on the view's permission_required entries pointing to annotations.view, annotations.change, and annotations.delete.\nIn label_studio/core/permissions.py, every permission is registered using rules.is_authenticated. Consequently, any successfully authenticated user satisfies the permission check, and no object-level organization test is executed during the request lifecycle.\nAttackers exploit this behavior through a step-by-step process. First, an authenticated user authenticates to their own legitimate account within one organization on the Label Studio instance. Second, because annotation identifiers are implemented as predictable sequential integers, the attacker crafts HTTP requests targeting specific annotation primary keys.\nThird, the attacker iterates through these sequential integer identifiers to read, modify, or delete annotations belonging to entirely different organizations on the same instance, bypassing all logical organizational boundaries due to the absence of tenant filtering in the underlying Django REST framework queryset evaluation."
}