Description

Top-level Slack channel messages can be forced into new per-message thread sessions when seedTopLevelRoomThread is enabled.

• Input: any user in a channel can send repeated messages that mention the bot (via app_mention, opts.wasMentioned, explicit <@​botUserId> mention, or regex mention logic in prepareSlackMessage).
• Behavior change: for such top-level room messages (not actual Slack thread replies), routing uses message.ts (or incomingThreadTs) as a synthetic threadId.
• Sink: resolveThreadSessionKeys() builds session keys by appending :thread:<threadId> to the base session key, creating a distinct persisted session entry per unique message.ts.

Although the session store has maintenance (default max entries), an attacker can still flood unique seeded thread keys to:

• churn/evict legitimate sessions (availability impact)
• increase disk I/O and CPU for frequent store updates

Vulnerable code (thread id seeding from top-level message ts):

const seedCandidateThreadId = threadContext.incomingThreadTs ?? threadContext.messageTs;
const seededRoomThreadId =
  !isThreadReply &&
  isRoom &&
  seedTopLevelRoomThread &&
  replyToMode !== "off" &&
  seedCandidateThreadId
    ? seedCandidateThreadId
    : undefined;
...
const routedThreadId = canonicalThreadId ?? (isRoomish ? seededRoomThreadId : undefined);
...
: resolveThreadSessionKeys({
    baseSessionKey: route.sessionKey,
    threadId: routedThreadId,
  });

Recommendation

Mitigate session-store flooding from untrusted channel traffic:

• Do not derive session/thread IDs from per-message timestamps for top-level channel messages unless there is a strong reason.
• Only enable seeding for trusted users (e.g., allowlisted) or when a command is detected, not for any mention.
• Add rate limiting / deduplication per channel+user for seeding events.
• Consider reusing a stable key for top-level mentions (e.g., channel:<id>:mentions), or only seed when the bot actually posts a thread reply.

Example approach (gate seeding behind allowlist or command):

const shouldSeed =
  isRoom &&
  !isThreadReply &&
  replyToMode !== "off" &&
  isTrustedSender &&
  isActionableCommand;

const seededRoomThreadId = shouldSeed ? threadContext.messageTs : undefined;

Description

resolveSlackRoutingContext uses Slack event fields (message.thread_ts / message.ts) directly to derive conversationId for runtime conversation bindings and as threadId for resolveThreadSessionKeys, without validating the value is a real Slack timestamp.

• Input: threadContext.incomingThreadTs and threadContext.messageTs originate from the inbound Slack event (message.thread_ts, message.ts).
• Propagation: seedCandidateThreadId = incomingThreadTs ?? messageTs and routedThreadId = canonicalThreadId ?? seededRoomThreadId.
• Sinks:
  • resolveRuntimeConversationBindingRoute({ conversationId: routedThreadId })
  • resolveThreadSessionKeys({ threadId: routedThreadId })

Although Slack normally emits timestamps in ^\d+\.\d+$ form, this code path does not enforce it. If an attacker can inject/forge Slack events (misconfigured webhook verification, compromised upstream, or non-Slack callers), a malformed thread_ts/ts could:

• cause conversation/session binding collisions by matching an existing binding key;
• create unexpected session keys (potentially impacting persistence keys, adapter lookups, or log/event correlation);
• increase risk when custom SessionBindingAdapter implementations assume conversationId is a Slack channel/thread identifier with a constrained format.

Vulnerable code:

const seedCandidateThreadId = threadContext.incomingThreadTs ?? threadContext.messageTs;
...
const routedThreadId = canonicalThreadId ?? (isRoomish ? seededRoomThreadId : undefined);
...
conversationId: routedThreadId,
...
threadId: routedThreadId,

Recommendation

Validate/normalize Slack timestamps before using them for routing/binding keys.

• Reuse the existing helpers in extensions/slack/src/thread-ts.ts (normalizeSlackThreadTsCandidate) when deriving any thread/session identifiers.
• If the value is invalid, treat it as undefined (no thread routing) and optionally log a warning.

Example fix:

import { normalizeSlackThreadTsCandidate } from "../../thread-ts.js";

const incomingThreadTs = normalizeSlackThreadTsCandidate(threadContext.incomingThreadTs);
const messageTs = normalizeSlackThreadTsCandidate(threadContext.messageTs);

const seedCandidateThreadId = incomingThreadTs ?? messageTs;
...
const routedThreadId = normalizeSlackThreadTsCandidate(
  canonicalThreadId ?? (isRoomish ? seededRoomThreadId : undefined),
);

This constrains conversationId/threadId to Slack’s expected ^\d+\.\d+$ format and reduces the risk of collisions or adapter/key misuse if events are ever spoofed.