Sometimes the best bugs are the simplest ones. You don’t need complex RCE chains or buffer-overflow wizardry to get at sensitive data. Sometimes it’s enough to simply… ask the server nicely, using a slightly different HTTP method. That’s exactly what happened during my recent penetration test of the Computer Vision Annotation Tool (CVAT) platform.
The bug I found earned the official identifier CVE-2024-47172 and a GitHub security advisory (GHSA-gxhm-hg65-5gh2). The flaw has been patched, so we can look under its hood without holding back.
The vulnerability received a score of 5.4 (vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N). Let’s see how the developers forgot a fundamental rule: never trust user input, nor the methods used to send it.
TL;DR - Key takeaways
- What Went Wrong?
- Proof of Concept
- What Was Leaking?
- How to Fix It? (Remediation)
What Went Wrong?
CVAT (vulnerable versions include Server: 2.16.3, UI: 1.64.5) is a powerful tool for data annotation in Computer Vision projects. It is organized into Projects, Tasks, and Jobs. Each of these has its own sequential numeric identifier (e.g. /api/jobs/2137).
When a standard, logged-in user tries to query the API for a task belonging to someone else using the GET method, the application works flawlessly. It returns a juicy:
Access control lists (ACLs) do exactly what they’re paid to. But what if we route the traffic through a tool like Burp Suite and, in the Repeater module, change the method from GET to PATCH?
Proof of Concept
By sending the modified request:
Suddenly the barrier wall vanishes. The server responds with HTTP/1.1 200 OK and spits out a full JSON of someone else’s task data! We bypassed the object-level permission check (Insecure Direct Object Reference — IDOR).
The Scale of the Problem
This flaw was present on many critical endpoints: /api/jobs/<ID>, /api/projects/<ID>, and /api/tasks/<ID>. All it took was the Intruder module, iterating the <ID> parameter (since it’s a plain int, brute-forcing is trivial) and harvesting other users’ data.
What Was Leaking?
Information such as project_id, organization_id, issues_url, target repository addresses (target_storage), and the details of assigned people (assignee, username, first_name, last_name). For an attacker, that’s a real goldmine for further reconnaissance or phishing attacks.
- project_id and organization_id — identifiers that allow mapping the victim’s organizational structure.
- assignee (username, first_name, last_name) — personal data of the assigned users.
- target_storage — target repository addresses, potentially exposing the cloud infrastructure.
- issues_url — links to bug trackers that may contain confidential project information.
Why Is This Dangerous?
Leaking this data is not just a privacy violation. The attacker gains a full picture of the organization: who works on which projects, what the infrastructure looks like, and where to look for the next vulnerabilities. It’s a perfect starting point for social-engineering attacks.
How to Fix It? (Remediation)
This case is a classic reminder of two crucial things in application security:
- Complete access control: Permission checks (access control) must be implemented for every endpoint and every supported HTTP method (GET, POST, PUT, PATCH, DELETE), not just the default GET.
- No more sequential IDs: Let’s finally stop using sequential numeric identifiers! Replacing plain IDs with random UUID values (a defense-in-depth approach) would mean that even with a badly written ACL, an attacker would face a drastically harder time blindly brute-forcing resource identifiers.
The Pentester’s Golden Rule
When testing an API, always juggle the methods (PUT, PATCH, DELETE, OPTIONS). Sometimes the server simply forgets that the door needs locking from the other side too.
Sequential IDs = trivial to guess (brute-force)
UUID v4 = 2122 possible values (Defense-in-depth)
Summary
CVE-2024-47172 is a textbook example of an IDOR vulnerability, where changing a single HTTP method (from GET to PATCH) was enough to bypass access control in the popular CVAT data-annotation tool. The flaw allowed enumeration and reading of other users’ data, their projects, tasks, and personal information. It was responsibly disclosed and patched, but it remains an excellent lesson: access control must cover every endpoint and every HTTP method, and sequential identifiers are an invitation to attackers.
Bibliography
The official NIST NVD entry describing the IDOR vulnerability in CVAT, rated CVSS 5.8.
The security advisory published on GitHub by the CVAT team, containing details of the vulnerability and information about the fix.
The OWASP category describing vulnerabilities related to improper object-level access control — exactly the type of flaw exploited in CVE-2024-47172.
The open-source repository of the CVAT data-annotation tool for machine learning and Computer Vision projects.