Greptile Summary

This PR fixes a regression introduced in v2026.3.1 where quoted Feishu interactive cards were reduced to the useless placeholder "[Interactive Card]". The fix is minimal and targeted: parseInteractiveCardContent now returns string | undefined instead of always returning a string, and the call site in parseQuotedMessageContent falls back to rawContent (the original JSON payload) when extraction yields nothing. This restores pre-regression behavior — downstream consumers receive the full card JSON rather than an opaque string — while still using structured text extraction for the known elements-based card shapes.

Key changes:

• parseInteractiveCardContent return type widened to string | undefined; all three "[Interactive Card]" returns replaced with undefined
• parseQuotedMessageContent uses extracted ?? rawContent so raw payload is preserved on extraction failure
• New regression test verifies the fallback with a schema-2.0 card that lacks a top-level elements array

Minor observation: There is no test for the edge case where elements is present but contains only elements with unrecognised tags (e.g. image, action, column_set). In that case texts stays empty, extracted becomes "", and the function returns undefined → rawContent. This is a behaviour improvement over the old "[Interactive Card]" return but is not explicitly covered by the test suite. It is not a bug — just a gap in test coverage.

Confidence Score: 4/5

• Safe to merge — the change is a small, focused fallback improvement with a direct regression test and no breaking side-effects.
• The diff is minimal (three return-value changes + one call-site tweak). The logic is easy to trace: undefined propagates the nullish-coalescing fallback to rawContent, which is strictly more informative than "[Interactive Card]". The new test correctly exercises the targeted path. The only deduction is the uncovered edge case where elements exists but all tags are unrecognised, leaving that behaviour improvement implicit rather than asserted.
• No files require special attention.

_{Last reviewed commit: 7df0e43}

🔒 Aisle Security Analysis

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

1. 🟠 Feishu interactive-card raw JSON fallback can leak sensitive data to logs/LLM context

Description

parseFeishuMessageContent() now returns the entire raw interactive-card JSON payload (rawContent) when text extraction fails.

This is risky because Feishu interactive cards commonly include:

• internal identifiers (chat/user/open_id/tenant ids)
• deep links (sometimes containing tokens or signed parameters)
• metadata and embedded fields not intended for display

Once returned as content, this raw JSON is treated as message text elsewhere (e.g., quoted message previews, thread-history bootstrap, and tool/action outputs), which can:

• expose sensitive data to application logs (preview logging)
• exfiltrate sensitive payloads to third-party LLM providers (thread history / quoted content included in agent prompts)
• surface raw payloads to other systems/consumers that expect only human-readable text

Vulnerable code (new behavior):

if (msgType === "interactive") {
  const extracted = parseInteractiveCardContent(parsed);
  return extracted ?? rawContent;
}

This behavior is also codified in the new test falls back to raw interactive payload when card structure is unknown.

Recommendation

Do not fall back to returning the full raw interactive-card JSON as message text.

Safer options:

1. Keep a placeholder when extraction fails (previous behavior), optionally with minimal non-sensitive context:

if (msgType === "interactive") {
  const extracted = parseInteractiveCardContent(parsed);
  return extracted ?? "[Interactive Card]";
}

2. If raw payload is needed for debugging, gate it behind an explicit debug/diagnostic flag and redact common sensitive fields before logging or returning it.

Additionally, consider storing raw card JSON in a separate field (not content) that is never logged or forwarded to LLM prompts by default.

2. 🟡 Unbounded interactive card JSON returned as message content (resource exhaustion risk)

Description

parseFeishuMessageContent() now falls back to returning the full raw interactive-card payload when extraction fails:

• Input rawContent comes directly from the Feishu API response (item.body.content).
• For msg_type === "interactive", if parseInteractiveCardContent() cannot recognize the expected card schema, the code returns rawContent unchanged.
• This can propagate very large interactive-card JSON into downstream flows that expect human-readable text (e.g., quoted-message fetch and thread-history fetch).
• The resulting large content is later embedded into agent prompts/history construction (e.g., buildFeishuAgentBody() uses quotedContent verbatim), increasing memory usage, token usage/cost, and risk of exceeding model/context limits or storage quotas.

Vulnerable code:

if (msgType === "interactive") {
  const extracted = parseInteractiveCardContent(parsed);
  return extracted ?? rawContent;
}

Recommendation

Apply a size cap / truncation (and ideally avoid embedding raw card JSON into prompts at all).

Options:

1. Keep a bounded placeholder fallback:

if (msgType === "interactive") {
  const extracted = parseInteractiveCardContent(parsed);
  return extracted ?? "[Interactive Card]";
}

2. If raw fallback is required for debugging, truncate to a safe maximum and annotate:

const MAX_LEN = 2000;
if (msgType === "interactive") {
  const extracted = parseInteractiveCardContent(parsed);
  if (extracted) return extracted;
  const truncated = rawContent.length > MAX_LEN
    ? rawContent.slice(0, MAX_LEN) + `… [truncated ${rawContent.length - MAX_LEN} chars]`
    : rawContent;
  return truncated;
}

Also consider keeping raw card JSON in a separate field that is not fed into LLM prompts or persisted in chat history.

3. 🟡 Untrusted Feishu interactive card JSON returned as message content (prompt/log injection risk)

Description

The Feishu message parser now falls back to returning the raw interactive card JSON payload when it cannot extract human-readable text.

This is risky because rawContent is untrusted, attacker-controlled message content received from Feishu. Returning it verbatim:

• Propagates arbitrary strings/markup-like sequences (e.g., spoofed [System: ...]-style instructions, control characters) into downstream consumers.
• The resulting content is later used in:
  • agent context construction (quoted message/thread history bodies), and
  • logging (quoted-message debug logs),
    without any escaping/sanitization.

If an attacker can cause an interactive message with unexpected schema to be present (e.g., via integrations/bots), they can inject misleading content into the LLM prompt context and/or forge log lines.

Vulnerable code:

if (msgType === "interactive") {
  const extracted = parseInteractiveCardContent(parsed);
  return extracted ?? rawContent;
}

Recommendation

Do not return raw interactive JSON as a fallback. Prefer a safe placeholder and/or a tightly-scoped, sanitized summary.

Option A (restore safe placeholder fallback):

if (msgType === "interactive") {
  const extracted = parseInteractiveCardContent(parsed);
  return extracted ?? "[Interactive Card]";
}

Option B (sanitized JSON preview with strict limits):

function safePreview(s: string, max = 500): string {
  ​// strip control chars + collapse whitespace to prevent log/prompt forging
  return s.replace(/[\u0000-\u001F\u007F]/g, " ").replace(/\s+/g, " ").slice(0, max);
}

if (msgType === "interactive") {
  const extracted = parseInteractiveCardContent(parsed);
  return extracted ?? `[Interactive Card: ${safePreview(rawContent)}]`;
}

Additionally, consider:

• enforcing a maximum length for content inserted into agent prompt/thread history
• escaping/normalizing newlines before logging quoted message content (CWE-117 hardening)

Analyzed PR: #32742 at commit 00c6634

_{Last updated on: 2026-03-22T05:38:05Z}

Closing this PR because the current mainline Feishu direction has moved on: the official plugin now covers streaming cards and v2 card support, so this older fix path is no longer necessary to keep advancing. If related gaps remain in the future, they should be revisited against the current Feishu implementation rather than continued from this branch.