Description

The /approve command can now be executed by senders who are otherwise blocked by the channel allowlist (params.command.isAuthorizedSender === false) if the channel plugin implements authorizeActorAction and returns an allow-by-default decision.

Data flow / reasoning:

• handleApproveCommand previously hard-blocked when !params.command.isAuthorizedSender.
• New logic allows bypassing that block when hasExplicitApprovalAuthorization is true.
• hasExplicitApprovalAuthorization becomes true when resolveApprovalCommandAuthorization(...).explicit && authorized.
• resolveApprovalCommandAuthorization sets explicit: true whenever a plugin returns any result (even { authorized: true }).
• Several channel plugins use createResolvedApproverActionAuthAdapter, which returns { authorized: true } when no approvers are configured (i.e., resolveApprovalApprovers(...) returns an empty list). This makes the authorization decision “explicit” and “authorized”, thereby bypassing the sender allowlist check.

Impact:

• In channels where /approve messages can still arrive from non-allowlisted senders (e.g., public Slack/Discord/other channel surfaces), a blocked sender can submit approvals (exec and/or plugin) when no approvers policy is configured.
• This is a privilege/boundary regression: “blocked from chat access” no longer implies “blocked from approving”.

Vulnerable code (bypass condition):

const hasExplicitApprovalAuthorization =
  (execApprovalAuthorization.explicit && execApprovalAuthorization.authorized) ||
  (pluginApprovalAuthorization.explicit && pluginApprovalAuthorization.authorized);

if (!params.command.isAuthorizedSender && !hasExplicitApprovalAuthorization) {
  return { shouldContinue: false };
}

Why this can happen (allow-by-default auth adapter):

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

Recommendation

Do not allow authorizeActorAction to bypass isAuthorizedSender when the channel’s approval policy is effectively “not configured”. Options:

1. Treat allow-by-default results as non-explicit in resolveApprovalCommandAuthorization.

   • Extend the adapter contract to return an explicit flag (or policyConfigured) and propagate it.

2. Gate the bypass on an affirmative configured approver policy.

   • Example (conceptual): only bypass when the plugin indicates approvers exist.

Example fix (minimal change: require an explicit deny/allow policy to be configured):

​// src/infra/channel-approval-auth.ts
const result = plugin?.auth?.authorizeActorAction?.(...);
if (!result) return { authorized: true, explicit: false };

​// If plugin returns allow without a reason/without policy, don’t treat as explicit.
if (result.authorized === true && result.reason === undefined) {
  return { ...result, explicit: false };
}
return { ...result, explicit: true };

Better: add a dedicated field:

type AuthzResult = { authorized: boolean; reason?: string; policyConfigured: boolean };

Then in /approve, only bypass isAuthorizedSender when policyConfigured && authorized.

Description

resolveTelegramExecApproval creates a new gateway client per Telegram callback and waits for a custom ready promise with no timeout.

Impact:

• If the gateway never invokes onHelloOk, onConnectError, or onClose (e.g., network stall, bug, partial connection), await ready can hang indefinitely.
• Each incoming approval callback triggers a fresh client (createOperatorApprovalsGatewayClient + .start()), so repeated callbacks can accumulate stuck connections/promises, causing resource exhaustion (sockets, memory, event loop pressure) and degraded availability.

Vulnerable code:

const ready = new Promise<void>((resolve, reject) => { /* ... */ });

const gatewayClient = await createOperatorApprovalsGatewayClient({
  onHelloOk: () => markReady(),
  onConnectError: (err) => failReady(err),
  onClose: (code, reason) => failReady(new Error(`gateway closed (${code}): ${reason}`)),
});

gatewayClient.start();
await ready; // no timeout

Recommendation

Add a bounded timeout for the pre-ready handshake and consider reusing a shared gateway client (or a small pool) rather than creating a new one per callback.

Example (timeout + cleanup):

const READY_TIMEOUT_MS = 10_000;

const readyWithTimeout = Promise.race([
  ready,
  new Promise<void>((_, reject) =>
    setTimeout(() => reject(new Error("gateway handshake timeout")), READY_TIMEOUT_MS)
  ),
]);

gatewayClient.start();
await readyWithTimeout;

Also consider rate limiting approval callbacks per sender/chat and ensuring stopAndWait() is invoked when the timeout fires (e.g., in a catch/finally).

Description

In bot-handlers.runtime.ts, the global self-message guard was removed and replaced with a DM-only check:

• Previously, all self-authored Telegram messages were ignored.
• Now, self-authored messages are only ignored when !isGroup.
• As a result, in groups/supergroups the bot may feed its own outbound messages back into the inbound pipeline (handleInboundMessageLike → processInboundMessage → processMessage → dispatchTelegramMessage).

If the Telegram Bot API delivers updates for the bot’s own messages in groups (common for many bot setups), this can cause:

• Feedback loops (bot responds to itself repeatedly)
• Unintended command/control-message handling if the bot outputs text beginning with / or otherwise triggers control-command parsing
• Resource exhaustion/DoS due to repeated LLM calls and message sends

Vulnerable code:

const isGroup = msg.chat.type === "group" || msg.chat.type === "supergroup";
...
​// only ignored for DMs now
if (!isGroup && normalizedMsg.from?.id != null && normalizedMsg.from.id === ctx.me?.id) {
  return;
}
await handleInboundMessageLike({ ... });

Recommendation

Reinstate a general self-message suppression for bot.on("message") (and any other inbound handlers where bot-authored updates can appear), unless there is an explicit, well-audited reason to allow self-authored group messages.

Example fix:

const botId = ctx.me?.id;
if (typeof botId === "number" && normalizedMsg.from?.id === botId) {
  return; // ignore bot's own messages in all chats
}

If self-authored group messages must be supported for a specific feature, gate it behind a dedicated config flag and add additional safeguards (e.g., tag outbound bot messages with an unambiguous marker and drop them on ingress, or only allow a strict subset of synthetic/internal commands).