GHSA-j68c-59h4-h9hg: 
JavaScript vulnerability analysis and mitigation

Summary

Moved here from a public issue that should have been reported privately.

What is wrong

Code capability calls authorize their chat differently from the other code chat routes. POST /api/assistant/artifacts/runtime/check/capability (and /runtime/capabilities) only check that the chat exists, is not archived, and that its tool scope contains the capability name. They do not check that the user can still read the chat's Project. Check start, record and gate for the same chat require the code_check / code_open grant and Project read, and return 403.

How to reproduce

# Scoped chat with allowedTools ["demo.read"] (no code_check), or a chat in a Project the user can no longer read:

# POST /runtime/check/start  -> 403

# POST /runtime/check/capability {"name":"demo.read","input":{},"conversationId":"<chat>"} -> 200
bun test packages/assistant/src/artifacts/chat-reference.test.ts   # route table shows the shared fixture

Suspected cause

packages/assistant/src/artifacts/capability-runtime.ts:73 (authorizeWithChat) resolves the chat itself instead of using requireToolChat from chat-access.ts, so it has no Project read check, and the check route passes the capability name as the grant.

Proposal

Decide whether capability calls from a chat must also require Project read (likely yes, like every other code chat path) and whether the check route should require code_check. Then route authorizeWithChat through requireToolChat.

Fix direction

Route capability calls through the same chat access check (requireToolChat in packages/assistant/src/artifacts/chat-access.ts) that check start, record and gate use, so a person who lost read access to the chat's Project can no longer run its capabilities.