CVE-2026-73221

CVE-2026-73221 exposes a horizontal privilege escalation in CVAT's lambda request API. Workers could retrieve and cancel lambda requests belonging to other users by predicting the request IDs — identifiers derived from task IDs using a deterministic pattern. This isn't a missing ACL check; it's a structural API design failure where the ID scheme itself encoded the authorization model, making enumeration trivial for any authenticated user. The vulnerability existed from version 2.17.0 through 2.72.0 — a 55-version window that went undetected because the flaw wasn't in code that could be reviewed. When authorization lives in predictable data relationships rather than explicit permission checks, it becomes invisible to standard diff-based review. There was nothing to flag in a pull request because the ID scheme wasn't treated as authorization surface; it was just how the system worked. The fix in 2.72.0 likely involved either introducing opaque, session-scoped tokens for lambda request identifiers, or adding authorization middleware that validates the user's relationship to the task before returning or destroying the request. Neither is trivial — both require decoupling a security-relevant identifier from infrastructure that likely depended on its predictability. You should treat this as a canary. If predictable ID schemes exist elsewhere in CVAT's API — task IDs, job IDs, annotation IDs — those endpoints may have the same implicit authorization vulnerability. Audit any endpoint that accepts a derived identifier and performs an operation without explicitly validating the caller's relationship to the underlying resource. The pattern is systematic: CVAT modeled resources around internal data relationships rather than access-controlled objects, and the lambda request endpoints are where that design philosophy broke surface.

Reviewed through automated stages and approved by a human before publication.