fix: [Security] fix task API ownership leakage

[13ernkastel]

Summary

• require authentication for the task polling endpoints and scope task reads to the authenticated owner
• persist task ownership metadata in the in-memory tracker without exposing it in API responses
• scope async reindex task deduplication to the same owner so one tenant cannot block another tenant's background task on the same URI string

Root Cause

/api/v1/tasks and /api/v1/tasks/{task_id} were mounted without get_request_context, and TaskTracker stored tasks in a single global namespace with no owner metadata. Any caller who could reach the server could enumerate or poll background task records created by other users, and async reindex deduplication also keyed only on the raw resource URI.

Impact

• unauthenticated callers could enumerate recent background tasks and retrieve per-task metadata
• exposed metadata could include task type, task status, resource identifiers, archive URIs, result payloads, and sanitized error strings from other users' activity
• in multi-tenant deployments, async reindex deduplication could also create low-grade cross-tenant interference when different users referenced the same URI string

Proof Of Concept

The issue is reproducible on the vulnerable code path before this patch:

1. Create a background task as a normal authenticated user:

   API_KEY='<valid-user-key>'
   BASE='http://127.0.0.1:1933'
   
   SESSION_ID=$(curl -s -X POST "$BASE/api/v1/sessions" \
     -H "X-API-Key: $API_KEY" \
     -H 'Content-Type: application/json' \
     -d '{}' | jq -r '.result.session_id')
   
   curl -s -X POST "$BASE/api/v1/sessions/$SESSION_ID/messages" \
     -H "X-API-Key: $API_KEY" \
     -H 'Content-Type: application/json' \
     -d '{"role":"user","content":"hello"}' >/dev/null
   
   TASK_ID=$(curl -s -X POST "$BASE/api/v1/sessions/$SESSION_ID/commit" \
     -H "X-API-Key: $API_KEY" \
     -H 'Content-Type: application/json' \
     -d '{}' | jq -r '.result.task_id')

2. From an unauthenticated client, enumerate tasks:

   curl -s "$BASE/api/v1/tasks" | jq

   Before the fix, this returns the other user's task metadata instead of 401.
3. From the same unauthenticated client, retrieve the specific task:

   curl -s "$BASE/api/v1/tasks/$TASK_ID" | jq

   Before the fix, this returns the task record for another user's background job instead of 401/404.

Classification

• Primary CWE: CWE-862 Missing Authorization
• Secondary CWE: CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
• CVSS v3.1: 5.3 Medium (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N)

Validation

• uvx ruff format --check openviking/service/task_tracker.py openviking/server/routers/tasks.py openviking/server/routers/content.py openviking/session/session.py tests/test_task_tracker.py tests/server/test_auth.py tests/server/test_api_content.py tests/test_session_task_tracking.py
• uvx ruff check openviking/service/task_tracker.py openviking/server/routers/tasks.py openviking/server/routers/content.py openviking/session/session.py tests/test_task_tracker.py tests/server/test_auth.py tests/server/test_api_content.py tests/test_session_task_tracking.py
• OPENVIKING_CONFIG_FILE=/tmp/openviking-security-test-ov.conf PYTHONPATH=/Users/lennonchia/Documents/Project/OpenViking-security /Users/lennonchia/Documents/Project/OpenViking/.venv/bin/python -m pytest tests/test_task_tracker.py tests/server/test_auth.py::test_task_endpoints_require_auth tests/server/test_auth.py::test_task_endpoints_are_user_scoped tests/server/test_api_content.py::test_reindex_uses_request_tenant_for_exists -q

Notes

• I checked for an existing upstream/internal duplicate around task endpoint auth and task ownership leakage before landing this branch and did not find one.
• This branch is based on upstream main plus this single security fix; it does not include unrelated fork-only changes.

[github-actions]

Failed to generate code suggestions for PR

[github-actions]

Failed to generate code suggestions for PR