In a pentester’s life it sometimes happens that you hit a great bug, rub your hands together, write the report, and then find out… someone else got to it just before you. The vulnerabilities I reported in the Computer Vision Annotation Tool (CVAT) platform turned out to be a duplicate, but significant enough to be tied to the official security advisory GHSA-p3c9-m7jr-jxxj and ultimately captured in CVE-2024-45393.
The flaw received a score of 6.4 (Moderate) with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N. Let’s look at how, once again, predictable identifiers and missing authorization on secondary endpoints enabled data theft and even created a DoS risk.
TL;DR - Key takeaways
- Webhooks Under the Microscope
- Vector 1: A Malicious Ping and the DoS Risk
- Vector 2: Delivery History
- How to Patch Such Bugs? (Remediation)
Webhooks Under the Microscope
CVAT lets users create projects and attach webhooks to them. It’s a useful feature: when something happens in a project, the application sends a notification to a URL of our choice.
The application (in the tested versions, including Server: 2.16.3) has two interesting endpoints for managing webhooks:
Both of these features concealed a classic Insecure Direct Object Reference (IDOR) and Horizontal Privilege Escalation flaw.
- One for testing (pinging) a webhook.
- One for checking the delivery history.
Vector 1: A Malicious Ping and the DoS Risk
When you create a webhook, the application sends a POST request to check whether the supplied URL responds. This traffic goes to the endpoint:
The <ID> parameter is, of course… a plain integer (e.g. 765). All it took was intercepting this request in Burp Suite and changing the ID to one belonging to another user. The result?
Instead of a 403 error, the server obediently "pinged" someone else’s webhook and returned a juicy JSON response. It leaked, among other things:
target_url(often containing internal corporate addresses or tokens in the URLs),project_idand organization,- Owner data:
username,first_name,last_name.
The DoS Risk
Since the identifiers are plain numbers, you can use Intruder and iterate webhook_id thousands of times. Beyond mass data theft (a data leak), this forces the CVAT server to send thousands of HTTP requests to third-party servers. Using parallelized requests (e.g. from a botnet), we could exhaust the application’s resources, triggering a classic Denial of Service (DoS) condition.
Vector 2: Delivery History
The second problem was in the webhook log history. It was served by the endpoint:
As with the ping, changing the <ID> allowed reading someone else’s event history. What’s most interesting about this vector, though, are the nested endpoints.
The application allowed querying a specific delivery, where both identifiers (webhook_ID and delivery_ID) are sequential numbers.
A Pentester’s Aside
It often happens that, after an IDOR report, developers patch the main endpoint (e.g. listing /deliveries) but forget to apply an Access Control List (ACL) to the nested endpoint querying a specific item (/deliveries/<delivery_ID>). Being able to guess (or brute-force) the delivery_ID, an attacker could still get at the data!
How to Patch Such Bugs? (Remediation)
Even though the report turned out to be a duplicate, the lesson from this vulnerability (now officially patched under CVE-2024-45393) is universal:
- Consistent Access Control (ACL): Verifying the session alone is not enough. On every request the server must check the rule: "Does user X have the right to access resource Y?" And it must do so on every endpoint, from the main
/webhooksto the deeply nested/webhooks/ID/deliveries/ID. - No more sequential identifiers: If CVAT used long, random strings (e.g. UUID v4) instead of values like
784or310, mass resource scanning with Burp Intruder would simply be impossible. It’s a perfect example of applying a defense-in-depth mechanism. Even if the ACL logic fails, the attacker still cannot guess the identifier of someone else’s resource.
Sequential IDs = trivial to guess (brute-force)
UUID v4 = 2122 possible values (Defense-in-depth)
Summary
CVE-2024-45393 is a double IDOR in the webhook mechanism of the CVAT platform. The first vector allowed pinging other users’ webhooks and stealing sensitive data (target_url, username, project_id), and under mass exploitation it created a DoS risk. The second vector allowed reading other users’ delivery history, including the nested endpoints. The flaw was responsibly disclosed and patched; the key lesson is the need to implement consistent access control on all endpoints and to abandon sequential identifiers.
Bibliography
The official NIST NVD entry describing the double IDOR vulnerability in CVAT webhooks, rated CVSS 6.4.
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-45393.
The open-source repository of the CVAT data-annotation tool for machine learning and Computer Vision projects.