Description

The Discord native approval adapter resolves the origin delivery target using request-controlled fields (turnSourceChannel/turnSourceTo) and a regex parse of sessionKey without verifying that these values are bound to an authenticated/recorded session.

This enables a forged approval request (exec or plugin) to cause the system to send approval content and/or the “check your DMs” redirect notice to an attacker-chosen Discord channel ID:

• If turnSourceChannel === "discord" and turnSourceTo is provided, the adapter accepts it even when turnSourceAccountId is missing/empty, so there is no binding to the configured Discord account.
• If session lookup fails or the session is not Discord, it falls back to extractDiscordChannelId(sessionKey) which only regex-parses digits from the provided sessionKey, allowing arbitrary channel IDs even when there is no session-store entry.

Vulnerable code:

if (turnSourceChannel === "discord" && turnSourceTo) {
  if (params.accountId && turnSourceAccountId && normalizeAccountId(turnSourceAccountId) !== normalizeAccountId(params.accountId)) {
    return null;
  }
  return { to: turnSourceTo };
}

const sessionTarget = resolveRequestSessionTarget(params);
if (!sessionTarget || sessionTarget.channel !== "discord") {
  const channelId = extractDiscordChannelId(params.request.request.sessionKey?.trim() || null);
  return channelId ? { to: channelId } : null;
}

Downstream, resolveChannelNativeApprovalDeliveryPlan can include this originTarget as a delivery target and/or use it for notifyOriginWhenDmOnly, leading to unauthorized messaging and potential leakage of approval details into arbitrary channels.

Recommendation

Do not trust turnSourceTo/sessionKey to select an origin channel unless it is cryptographically/authentically bound to a previously recorded session.

Recommended fixes (choose one or combine):

1. Remove the regex fallback and only allow origin resolution from a validated session-store entry:

const sessionTarget = resolveRequestSessionTarget(params);
if (!sessionTarget || sessionTarget.channel !== "discord") return null;

2. If turnSourceTo is allowed, require turnSourceAccountId and verify it matches the configured account, and ensure the origin target matches what’s stored for the session (or another server-side mapping) rather than taking arbitrary IDs:

if (turnSourceChannel === "discord" && turnSourceTo) {
  if (!params.accountId || !turnSourceAccountId) return null;
  if (normalizeAccountId(turnSourceAccountId) !== normalizeAccountId(params.accountId)) return null;
  ​// optionally: verify turnSourceTo equals sessionTarget.to (if sessionKey present)
}

3. Consider setting requireMatchingTurnSourceChannel: true for Discord as well, and/or introduce a signed origin token that cannot be forged by plugins/clients.

Description

The new /approve routing allows requests when there is an explicit channel approval authorization (resolveApprovalCommandAuthorization(...).explicit && authorized) even if params.command.isAuthorizedSender is false.

Several channel plugins implement auth.authorizeActorAction via createResolvedApproverActionAuthAdapter(). That helper currently default-allows approvals when the resolved approvers list is empty:

• authorizeActorAction returns { authorized: true } when approvers.length === 0
• Because authorizeActorAction exists, resolveApprovalCommandAuthorization() marks the result as explicit: true
• handleApproveCommand then treats this as an explicit approval grant and accepts /approve from otherwise-unauthorized senders

Impact:

• If an operator has a channel plugin with approval auth enabled but has not configured any approvers (or configuration resolves to an empty approvers list), any user who can message the bot in that channel can approve exec/plugin approvals, bypassing command allowlists/owner checks.

Vulnerable code:

const approvers = params.resolveApprovers({ cfg, accountId });
if (approvers.length === 0) {
  return { authorized: true } as const;
}

Recommendation

Change the default behavior so an empty approver list does not grant approval permission.

Safer options:

1. Treat empty approvers as “no explicit approval auth configured” and let callers fall back to other checks (e.g., params.command.isAuthorizedSender). You can do this by returning undefined (so resolveApprovalCommandAuthorization() sets explicit:false) or by returning { authorized: true, explicit: false } in a different interface.

2. Fail closed when approvers are empty:

const approvers = params.resolveApprovers({ cfg, accountId });
if (approvers.length === 0) {
  return {
    authorized: false,
    reason: `❌ No approvers are configured for ${approvalKind} approvals on ${params.channelLabel}.`,
  } as const;
}

Additionally, consider updating /approve gating to require either params.command.isAuthorizedSender or an explicit approval auth that is backed by a non-empty allowlist/approver set.

Description

In the Telegram callback handler, failures while resolving an approval callback are replied back into the originating chat with the raw stringified error.

• Input: the approval callback is triggered in a chat (often a group/supergroup) by any user pressing an inline button.
• Sink: replyToCallbackChat sends errStr (derived from String(resolveErr)) into the chat.
• Impact: internal error messages can disclose sensitive operational details (gateway URL/state, IDs, stack fragments, or upstream service responses). This is particularly risky in group chats where many users can see the message.

Vulnerable code:

} catch (resolveErr) {
  const errStr = String(resolveErr);
  logVerbose(`telegram: failed to resolve approval callback ${approvalCallback.approvalId}: ${errStr}`);
  await replyToCallbackChat(`❌ Failed to submit approval: ${errStr}`);
  return;
}

Recommendation

Do not echo raw exception strings to chats. Return a generic error to the user and log full details server-side.

Example:

} catch (resolveErr) {
  logVerbose(
    `telegram: failed to resolve approval callback ${approvalCallback.approvalId}: ${String(resolveErr)}`,
  );
  await replyToCallbackChat("❌ Failed to submit approval. Please try again or contact an administrator.");
  return;
}

Optionally, map known gateway errors to user-safe messages (e.g., "approval expired") and omit untrusted/verbose details.

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".