fix(security): prevent cross-channel reply routing in shared sessions by brandonwise · Pull Request #24571 · openclaw/openclaw

brandonwise · 2026-02-23T15:19:28Z

Summary

Fixes #24152 — cross-channel reply routing privacy leak in shared sessions.

Problem

When dmScope="main" (the default), all DM channels share a single session. The session's lastChannel/lastTo fields get overwritten by each inbound message, regardless of source channel.

Race condition: If a Slack DM arrives while the agent is generating a WhatsApp reply, lastChannel flips to "slack" and the reply routes to the Slack sender instead of the WhatsApp user — a privacy violation.

Reproduction conditions (from issue):

Active WhatsApp conversation in progress
Incoming Slack system message (team member DM)
Agent generates response → delivered to Slack DM instead of WhatsApp

Fix

Adds optional turnSourceChannel, turnSourceTo, turnSourceAccountId, and turnSourceThreadId parameters to:

resolveSessionDeliveryTarget() in targets.ts
resolveAgentDeliveryPlan() in agent-delivery.ts

When turnSourceChannel is set, it overrides the session-level lastChannel for "last" channel resolution. This ensures the reply always routes back to the channel that originated the turn, regardless of concurrent inbound messages from other channels.

Key design decisions:

Backward compatible — all new parameters are optional; existing call sites work unchanged
Opt-in — callers pass the originating channel context when they want cross-channel safety
No session schema changes — operates at the delivery resolution layer, not storage
Follows existing patterns — mirrors the requestedChannel / explicitTo parameter style

Changes

File	Change
`src/infra/outbound/targets.ts`	Add `turnSource*` params to `resolveSessionDeliveryTarget()`
`src/infra/outbound/agent-delivery.ts`	Add `turnSource*` params to `resolveAgentDeliveryPlan()`, pass through to target resolution
`src/infra/outbound/targets.test.ts`	4 new test cases for cross-channel guard

Test cases

✅ turnSourceChannel overrides session lastChannel when provided
✅ Falls back to session lastChannel when turnSourceChannel is absent
✅ Explicit requestedChannel takes priority over turnSourceChannel
✅ Preserves turnSourceAccountId and turnSourceThreadId

Next steps

Upstream callers (channel monitors, agent turn pipeline) need to pass turnSourceChannel when initiating turns. This PR provides the infrastructure; wiring the callers is a follow-up.

AI-assisted: Claude analyzed the routing code and authored the fix. Human reviewed the approach and design decisions.

Greptile Summary

Adds optional turnSource* parameters to delivery resolution functions to prevent cross-channel reply routing in shared sessions (dmScope="main"). When a turn originates from WhatsApp but a concurrent Slack message updates the session's lastChannel, replies could be misrouted to Slack—this fix ensures replies route back to the originating channel by letting callers override session state with turn-specific context.

Key changes:

resolveSessionDeliveryTarget() and resolveAgentDeliveryPlan() accept new optional turnSourceChannel, turnSourceTo, turnSourceAccountId, and turnSourceThreadId parameters
When turnSourceChannel is set, it overrides session-level lastChannel for "last" channel resolution
Backward compatible—all parameters optional, existing call sites unchanged
Test coverage includes cross-channel guard scenarios and priority handling

As noted in PR description: This provides the infrastructure; upstream callers (channel monitors, agent turn pipeline) need updates in follow-up work to pass turn source context.

Confidence Score: 5/5

Safe to merge with minimal risk—addresses privacy issue with backward-compatible infrastructure
Clean implementation following existing patterns, comprehensive test coverage for new functionality, well-documented with issue references, backward compatible design, and PR explicitly scopes this as infrastructure-only (follow-up needed for caller integration)
No files require special attention

_{Last reviewed commit: 53250c8}

arosstale

Clean fix for a real privacy bug. The turn-source channel override pattern is the right approach — it pins reply routing to the originating channel rather than trusting the mutable session-level lastChannel. The null-coalescing fallbacks (turnSourceTo ?? context?.to) preserve backward compatibility when the caller doesn't set the new fields. Tests cover the cross-channel race. LGTM.

…onwise

…onwise)

steipete · 2026-02-25T01:41:51Z

Landed via temp rebase onto main.

Gate: pnpm check && pnpm build && pnpm test && pnpm check:docs (full test run hit unrelated flaky src/gateway/server.auth.test timeout assertion); pnpm test src/infra/outbound/targets.test.ts src/infra/outbound/agent-delivery.test.ts src/commands/agent.delivery.test.ts src/gateway/server-methods/agent.test.ts
Land commit: 93dc388
Merge commit: 389ccda

Thanks @brandonwise!

…onwise

…onwise)

…onwise

…onwise)

…onwise

…onwise)

…@brandonwise

…@brandonwise)

…@brandonwise

…@brandonwise)

…@brandonwise

…@brandonwise)

…@brandonwise

…@brandonwise)

…@brandonwise

…@brandonwise)

…@brandonwise

…@brandonwise) (cherry picked from commit 885452f) # Conflicts: # src/infra/outbound/agent-delivery.ts # src/infra/outbound/targets.test.ts # src/infra/outbound/targets.ts

…@brandonwise

…@brandonwise) (cherry picked from commit 885452f) # Conflicts: # src/infra/outbound/agent-delivery.ts # src/infra/outbound/targets.test.ts # src/infra/outbound/targets.ts

…rce routing This fixes group message routing failures introduced in v2026.2.24 when PR openclaw#24571 added fail-closed security hardening for shared-session cross-channel replies. The issue: `buildEmbeddedContextFromTemplate` was only setting `messageProvider` but not `messageChannel`. The delivery planner's `turnSourceChannel` logic reads from `runContext.messageChannel`, so without it set, the turn-source binding fails and replies to group messages don't route back to the originating channel. This affects all plugin-based channels (Mattermost, etc.) and potentially built-in channels (Telegram, WhatsApp) in group/channel contexts where the session might be shared across channels. The fix adds `messageChannel` alongside `messageProvider` using the same resolved value from `resolveOriginMessageProvider`. Related issues: - openclaw#24571 (original security hardening PR) - openclaw#29637 (Telegram group messages not working) - openclaw#19509 (WhatsApp group messages not working) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

…tibility The change in v2026.2.24 that made pairing store DM-only broke existing setups where users relied on DM pairing to access group chats. This restores the previous behavior where storeAllowFrom is included in effectiveGroupAllowFrom. Note: Command authorization in groups still requires explicit allowlist (not pairing store) to maintain security separation. See: openclaw#24571 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

…tibility The change in v2026.2.24 that made pairing store DM-only broke existing setups where users relied on DM pairing to access group chats. This restores the previous behavior where storeAllowFrom is included in effectiveGroupAllowFrom. Added groupAuthIncludesPairingStore option (defaults to true) for users who want to opt into the stricter v2026.2.24 behavior. Note: Command authorization in groups still requires explicit allowlist (not pairing store) to maintain security separation. See: openclaw#24571 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>