GHSA-hfpr-jhpq-x4rm

This commit introduced the new /approve text command and its handler called exec.approval.resolve after checking only isAuthorizedSender, with no gateway-client scope restriction for internal channels. The later fix adds exactly that missing authorization gate by requiring operator.approvals or operator.admin via requireGatewayClientScopeForInternalChannel. Since the vulnerable behavior was created when /approve was first added here, this commit is the bug-introducing commit.

• •At 483fba41, src/auto-reply/reply/commands-approve.ts was newly added and contains no check of params.ctx.GatewayClientScopes or internal-channel scope before invoking callGateway({ method: "exec.approval.resolve", ... }).
• •The fix for this same file replaces/augments the prior logic with requireGatewayClientScopeForInternalChannel(params, { allowedScopes: ["operator.approvals", "operator.admin"] ... }), showing the security issue was missing scope enforcement for gateway clients on internal channels.
• •Repository search at the introducing commit found no command-gates usage, no isInternalMessageChannel check, and no GatewayClientScopes handling in the /approve handler, confirming the omission existed from the moment the command was introduced.

The vulnerability allows users with `operator.write` scope to execute admin-only `/config set` and `/config unset` commands. The fix commit addresses this by adding an `operator.admin` scope check in `src/auto-reply/reply/commands-config.ts`. To do this, it refactored existing scope checking logic from `src/auto-reply/reply/commands-approve.ts` into a shared helper function. The suspected commit is simply the commit that originally added `commands-approve.ts`. It did not introduce the vulnerability in `commands-config.ts`, and was likely flagged by the blame tool only because the fix commit modified `commands-approve.ts` during the refactoring process.

• •The fix commit `5f8f58ae25e2a78f31b06edcf26532d634ca554e` adds an `operator.admin` scope check to `src/auto-reply/reply/commands-config.ts` for `/config set` and `/config unset` commands.
• •To implement this fix, the fix commit refactored existing scope checking logic from `src/auto-reply/reply/commands-approve.ts` into a shared helper function `requireGatewayClientScopeForInternalChannel`.
• •The suspected commit `483fba41b9f9fb57964f31b90a2ddacb185d54d7` is the commit that originally added `src/auto-reply/reply/commands-approve.ts`. It did not touch `commands-config.ts` or introduce the missing authorization check for config writes.

The vulnerability (GHSA-hfpr-jhpq-x4rm) is about `operator.write` chat.send being able to reach admin-only config writes in `commands-config.ts`. The fix commit adds a `requireGatewayClientScopeForInternalChannel` check requiring `operator.admin` scope to `commands-config.ts` for set/unset operations. The suspected BIC (483fba41) only created `commands-approve.ts` and did NOT modify `commands-config.ts` at all — the config command handler already existed before this commit and already lacked the admin scope check. The changes to `commands-approve.ts` in the fix are merely a refactor of an existing scope check to use a shared utility, not the actual security fix.

• •The BIC commit (483fba41) only created commands-approve.ts and did not modify commands-config.ts
• •The actual vulnerability fix is the addition of requireGatewayClientScopeForInternalChannel with operator.admin scope to commands-config.ts for set/unset operations
• •commands-config.ts existed before the BIC and already lacked the admin scope check for config writes
• •The changes to commands-approve.ts in the fix commit are a refactor of existing scope checks to use a shared utility, not the core security fix