When an Application Says Too Much. Information Exposure in CVAT (No CVE)

Why Are Information-Leak Bugs Dangerous?

Before we get to the specifics, one thing is worth noting: information disclosure rarely leads directly to server takeover (RCE). It is, however, the foundation of reconnaissance.

From an attacker’s perspective, every piece of information about system paths, the technologies in use, or internal network addressing is like finding a bank’s architectural blueprints before the heist. It lets you pick the next exploits more precisely.

In CVAT I found two vectors for leaking sensitive diagnostic data.

Vector 1: An Invalid "Remote Source" and Server Path Leakage

When creating a new Task in CVAT, we can point to a "Remote Source" as the file origin (e.g. a link to a network resource). But what happens if we supply a malicious or junk URL to a domain that returns no valid files to parse?

Instead of a standard "Could not download file" error, the backend (built on the Django framework) "chokes" and throws a full system error into the user interface and directly into the API response:

By this simple means I learned exactly which directory the application runs in on the server, under what privileges (or on what structure) it operates, and how it internally maps task identifiers to folders on the hard drive.

For an attacker looking for, say, a Local File Inclusion (LFI) or Path Traversal vulnerability, that’s a valuable clue.

Vector 2: Internal Architecture Uncovered via Lambda Functions

The second vector was a bit cleverer and involved the Lambda functions feature. I used plain iteration (brute-force) of API request identifiers:

When the application could not find a function with a given number (because, say, it didn’t exist or I had no access to it), the server responded with HTTP 404 Not Found. This was not a standard, short message, though. The server response contained a detailed log:

• We know that Nuclio is used under the hood to handle serverless/lambda.
• We know that communication runs unencrypted over HTTP on port 8070.
• We learned the internal network addressing (Internal Domain): nuclio-dashboard.internal.cvat.ai.

How to Silence an Over-Talkative Application? (Remediation)

Even if the developers ignored the report, the principles of secure programming (and error handling) remain unchanged.

• Exception Handling — System errors and exceptions should never surface (to the end user’s view). Use try/catch blocks in a deliberate, planned way.
• Generic error messages — When the application cannot process a path or connect to a microservice, the user should see only a safe, generic message: "An error occurred while processing the file" or "Resource not found".
• Server-side logging — Stack traces, [Errno 21] errors, and port information (8070) should go only to system logs accessible only to administrators or SOC/QA teams.
• Static analysis (SAST) — Static Application Security Testing tools can easily flag where the code lacks sanitization of application errors surfaced externally.