{"id":"GHSA-hjwc-26pj-v3pm","title":"AgenticMail: Cross-agent task authorization bypass in AgenticMail API","summary":"AgenticMail: Cross-agent task authorization bypass in AgenticMail API","severity":"high","cwe":["CWE-639","CWE-862"],"vendor":"agenticmail","product":"@agenticmail/api","affected":["@agenticmail/api < 0.9.64"],"patched":["@agenticmail/api 0.9.64"],"published":"2026-06-18","updated":"2026-06-18","source":"GHSA","sourceUrl":"https://github.com/advisories/GHSA-hjwc-26pj-v3pm","references":[{"url":"https://github.com/agenticmail/agenticmail/security/advisories/GHSA-hjwc-26pj-v3pm"},{"url":"https://github.com/advisories/GHSA-hjwc-26pj-v3pm"}],"tags":["ghsa","npm"],"ingestedAt":"2026-06-19T03:39:00.794Z","ecosystem":"npm","slug":"GHSA-hjwc-26pj-v3pm","body":"## Overview\n\n## Summary\n\nA low-privileged authenticated AgenticMail agent can enumerate another agent's pending/claimed tasks by supplying the target agent name to `GET /api/agenticmail/tasks/pending?assignee=<name>`. The returned task objects include the task IDs and payloads. The same task IDs can then be used with the capability-style task mutation endpoints (`/tasks/:id/claim`, `/tasks/:id/result`, `/tasks/:id/complete`, `/tasks/:id/fail`) to claim, complete, or fail tasks assigned to a different agent.\n\nBecause ordinary authenticated agents can discover agent names through `GET /api/agenticmail/accounts/directory`, the task ID effectively stops being a secret capability. This turns the intended capability model into a cross-agent authorization bypass.\n\n## Affected component\n\nPackage: `@agenticmail/api`\nObserved version: `0.9.62`\nRepository: `agenticmail/agenticmail`\n\nRelevant code paths:\n\n- `packages/api/src/app.ts`: `createAuthMiddleware(...)` is mounted before `createAccountRoutes(...)` and `createTaskRoutes(...)`, so these routes are reachable by any valid bearer token.\n- `packages/api/src/routes/accounts.ts`: `GET /accounts/directory` is available to any authenticated user and returns agent names.\n- `packages/api/src/routes/tasks.ts`: `GET /tasks/pending?assignee=name` resolves arbitrary agent names and returns that agent's pending/claimed tasks.\n- `packages/api/src/routes/tasks.ts`: `/tasks/:id/claim`, `/tasks/:id/result`, `/tasks/:id/complete`, `/tasks/:id/fail`, and `/tasks/:id` do not check whether the authenticated caller is the task assignee, assigner, or otherwise authorized for the task.\n\n## Impact\n\nAn attacker only needs a valid agent API key. They can:\n\n1. List agent names using `/accounts/directory`.\n2. Query another agent's task queue using `/tasks/pending?assignee=<victimName>`.\n3. Read sensitive task payloads intended for the victim agent.\n4. Use the disclosed task ID to complete/fail/claim the victim's task or submit attacker-controlled results.\n\n## Local reproduction\n\nI reproduced this locally with a focused Vitest test mounted directly on `createTaskRoutes`. The test creates two agents, Alice and Bob, and one pending task assigned to Bob. Alice authenticates with her own agent key and performs the following sequence:\n\n1. `GET /api/agenticmail/tasks/pending?assignee=Bob` with `Authorization: Bearer ak_alice`.\n2. The response is HTTP 200 and includes Bob's task ID and payload: `task-for-bob`, `{ \"task\": \"secret task intended for Bob\" }`.\n3. Alice then sends `POST /api/agenticmail/tasks/task-for-bob/complete` with her own bearer token and an attacker-controlled result.\n4. The task status becomes `completed` and the stored result is controlled by Alice.\n\nThe local verification command was:\n\n```bash\nnpm run test --workspace=@agenticmail/api -- task-routes-authz.test.ts\n```\n\nResult:\n\n```text\nPASS src/__tests__/task-routes-authz.test.ts (1 test)\n```\n\n## Expected behavior\n\nTask listing and task mutation endpoints should enforce an authorization relationship between the authenticated caller and the task. For example:\n\n- `GET /tasks/pending?assignee=<name>` should either be restricted to the current agent, master/admin callers, or an explicit delegated relationship.\n- `/tasks/:id/claim`, `/tasks/:id/result`, `/tasks/:id/complete`, `/tasks/:id/fail`, and `/tasks/:id` should verify that the caller is the assignee, assigner, master/admin, or otherwise explicitly authorized.\n- If capability-based task IDs are retained, the API should not expose those IDs to unrelated agents through the assignee-name listing path.\n\n## Credit\n\nPlease credit the finder as: Yaohui Wang\n\n## Affected packages\n\n- `@agenticmail/api < 0.9.64`\n\n## Remediation\n\nUpgrade to a patched release:\n\n- `@agenticmail/api 0.9.64`","depth":"twilight","depthScore":41,"depthScoreParts":{"impact":41.3,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}