🔒 Aisle Security Analysis

We found 3 potential security issue(s) in this PR:

1. 🟠 Global Discord component registry exposed via globalThis enables plugin-side interaction hijacking

Description

The Discord component registry was changed from module-local Maps to process-global Maps stored on globalThis using Symbol.for(...) keys.

This creates a new, stable, guessable access path for any in-process code (including third-party plugins) to read and overwrite registered component entries/modals, which are later trusted when dispatching interactions.

Impact (assuming plugins are not fully trusted):

• A plugin can obtain direct references to the registry maps via globalThis[Symbol.for(...)].
• It can enumerate existing component IDs and their associated metadata (e.g., callbackData, sessionKey, agentId, accountId, allowedUsers, messageId).
• It can overwrite entries (Map#set) to redirect future button/select/modal interactions to attacker-controlled callbackData and/or route overrides.
• The interaction dispatch path resolves entries by componentId only (no mandatory binding to messageId/channel), so an overwritten entry can be used even when it does not actually belong to the interacted message.

Vulnerable code:

const DISCORD_COMPONENT_ENTRIES_KEY = Symbol.for("openclaw.discord.componentEntries");

function resolveGlobalMap<TKey, TValue>(key: symbol): Map<TKey, TValue> {
  const globalStore = globalThis as Record<PropertyKey, unknown>;
  if (globalStore[key] instanceof Map) {
    return globalStore[key] as Map<TKey, TValue>;
  }
  const created = new Map<TKey, TValue>();
  globalStore[key] = created;
  return created;
}

This is a capability/authorization issue at the plugin boundary: it bypasses package export boundaries and enables cross-plugin tampering with interactive routing state.

Recommendation

If plugins are not meant to be fully trusted, avoid exposing mutable interaction routing state through a globally discoverable key.

Recommended mitigations (choose based on intended trust model):

1. Remove global exposure (strongest): keep the registry module-local (as before), or centralize it in a single internal module instance (dedupe imports) rather than using globalThis.

2. Scope + validate lookups (reduces hijack blast radius): key entries by (messageId, componentId) and require interaction.message.id to match at resolution time.

Example approach:

​// Store
componentEntries.set(`${messageId}:${entry.id}`, normalized);

​// Resolve
export function resolveDiscordComponentEntry(params: {
  messageId: string;
  id: string;
  consume?: boolean;
}): DiscordComponentEntry | null {
  const key = `${params.messageId}:${params.id}`;
  const entry = componentEntries.get(key);
  ​// ...expiry + consume...
}

3. Hardening: refuse overwrites unless the caller proves ownership (e.g., store a per-message nonce generated at send-time and require it to register/overwrite entries).

Also consider making any global registry key non-discoverable (not Symbol.for with a public string) unless you explicitly accept that any in-process code can tamper with it.

2. 🟡 Discord component button callbackData treated as raw CommandBody (internal command injection via one-click buttons)

Description

In Discord component fallback handling, raw callbackData from a button is now used directly as the synthesized inbound event text when no plugin handler matches.

Because eventText is later copied into CommandBody/BodyForAgent, a button click can inject arbitrary slash/bang command strings into the normal command-processing pipeline.

• callbackData is not validated/allow-listed for fallback handling
• For buttons, eventText becomes callbackData.trim() (e.g. tests show /codex_resume --browse-projects)
• dispatchDiscordComponentEvent() builds an inbound context where CommandBody is set to eventText, enabling built-in/plugin command parsing on a click

This creates a confused-deputy / command-injection primitive if untrusted content can influence button callbackData (e.g., LLM-generated interactive replies or plugin-provided components), turning a click on an innocuous-looking label into execution of internal chat commands (e.g., /reset, /config, !…), subject to whatever authorization gates evaluate true for the click sender.

Vulnerable code (button fallback uses raw callbackData):

const eventText =
  (consumed.kind === "button" ? consumed.callbackData?.trim() : undefined) ||
  formatDiscordComponentEventText({ ... });

And later (same file) eventText is propagated as command input:

• CommandBody: eventText
• BodyForAgent: eventText

Recommendation

Treat button callbackData as data, not as raw command text for the command parser.

Options (pick one):

1. Do not feed callbackData into CommandBody (keep it for agent context only):

const callbackText = consumed.kind === "button" ? consumed.callbackData?.trim() : undefined;
const fallbackText = formatDiscordComponentEventText({
  kind: consumed.kind === "select" ? "select" : "button",
  label: consumed.label,
  values,
});

const eventTextForAgent = callbackText || fallbackText;
const eventTextForCommands = fallbackText; // prevents slash/bang injection via button value

​// then use eventTextForCommands for CommandBody / BodyForCommands,
​// and eventTextForAgent for BodyForAgent.

2. If synthetic commands-from-buttons are required, gate them explicitly:

• only allow when commandAuthorized === true and callbackData matches an allow-list of permitted commands/namespaces
• otherwise fall back to formatDiscordComponentEventText().

This preserves Telegram-like behavior without allowing arbitrary command strings to be executed from untrusted button payloads.

3. 🔵 Discord plugin bind approval outcome disclosed by editing the public prompt message

Description

The Discord plugin binding approval flow now patches the original component message with the resolved approval/denial text.

• The edited message is a normal channel message (non-ephemeral), so anyone with access to the channel can see whether a plugin bind request was allowed or denied.
• Previously, the flow cleared the buttons and delivered the decision via an ephemeral follow-up, avoiding disclosure of approval outcomes to other channel members.

Vulnerable code:

const approvalMessageId = params.messageId?.trim() || params.interaction.message?.id?.trim();
if (approvalMessageId) {
  await editDiscordComponentMessage(
    normalizedConversationId,
    approvalMessageId,
    { text: buildPluginBindingResolvedText(resolved) },
    { accountId: params.ctx.accountId },
  );
}

Recommendation

Avoid putting the approval decision text into a public channel message.

Safer options:

1. Only clear/disable the components on the original message (no decision text), and always send the decision via an ephemeral follow-up to the clicker.
2. If you must edit the original message, replace it with a generic status (e.g., "Approval handled") that does not disclose allow/deny outcome.

Example (generic edit + ephemeral follow-up):

await respond.clearComponents({ text: "Approval handled." });
await respond.followUp({
  text: buildPluginBindingResolvedText(resolved),
  ephemeral: true,
});

Analyzed PR: #51260 at commit 76eb184

_{Last updated on: 2026-03-21T18:14:39Z}

Greptile Summary

This PR fixes a Discord /codex_resume picker regression where buttons would immediately show This component has expired. by addressing two root causes: (1) the component registry Maps were module-local, so separate ESM instances of the module couldn't share state between the sender and the listener; and (2) the built-in fallback path was discarding explicit callbackData payloads instead of forwarding them as the agent body (matching the Telegram behaviour).

Key changes:

• components-registry.ts: replaces module-local Map declarations with a resolveGlobalMap helper that stores the Maps on globalThis under Symbol.for()-keyed symbols, ensuring all duplicate module instances share the same backing store while preserving the existing TTL / consume / clear semantics unchanged.
• agent-components.ts: the fallback path after a plugin-dispatch miss now uses consumed.callbackData?.trim() as eventText before falling back to formatDiscordComponentEventText, so synthetic command strings (e.g. codexapp:<token>) are forwarded correctly.
• Two new tests cover the cross-module-instance sharing contract and the raw-callbackData fallback path respectively.

The implementation is clean and well-scoped. No issues were found.

Confidence Score: 5/5

• This PR is safe to merge — it is a targeted, well-tested bug fix with no backwards-incompatible changes and no new security surface.
• Both root causes of the expiration bug are addressed with minimal, focused changes. The global-singleton pattern using Symbol.for() is an established idiom for cross-instance state sharing in Node.js and is implemented correctly. The callbackData fallback path is logically correct (the ?.trim() || idiom handles null, undefined, and empty-string edge cases properly). Two new regression tests directly cover the two changed code paths, and the existing test suite is not broken. No security, auth, or data-handling changes were introduced.
• No files require special attention.

_{Last reviewed commit: "Discord: share compo..."}