Summary

• Fail closed for Telegram group sender authorization by removing DM pairing-store fallback from group allowlist evaluation.
• Keep group sender checks strictly bound to explicit group config (groupAllowFrom and per-group/per-topic allowFrom).
• Add regression coverage proving a DM-paired sender cannot bypass Telegram group allowlists.

Change Type

• Security fix
• Tests

Scope

• src/telegram/bot/helpers.ts
• src/telegram/bot-message-context.ts
• src/telegram/bot.create-telegram-bot.test.ts

Security Impact

• Boundary crossed before fix: DM pairing state (readChannelAllowFromStore("telegram")) was merged into group sender authorization.
• Exploit path: a sender paired for DM access but absent from groupAllowFrom could still trigger group message handling under groupPolicy="allowlist".
• Practical impact: unauthorized group-triggered bot actions in Telegram groups/channels where allowlist policy should block that sender.

Repro + Verification

Deterministic regression scenario:

1. Configure Telegram with groupPolicy: "allowlist" and groupAllowFrom: ["222222222"].
2. Pair/approve DM sender 123456789 (so it exists in pairing store).
3. Send group message from sender 123456789.
4. Before fix: message is processed.
5. After fix: message is blocked.

Targeted checks:

pnpm test src/telegram/bot.create-telegram-bot.test.ts -- --maxWorkers=1
pnpm test src/telegram/bot-message-context.sender-prefix.test.ts src/telegram/bot-native-commands.plugin-auth.test.ts -- --maxWorkers=1

Evidence

• New regression test:
  • blocks group sender not in groupAllowFrom even when sender is paired in DM store
• Related but different open PRs:
  • Telegram empty-override hardening only: fix(telegram): fail closed on empty group allowFrom override #25954
  • LINE pairing-store/group bypass: security(line): fail closed group allowlist against DM pairing store #25978
• Open PR search used for dedupe:
  • https://github.com/openclaw/openclaw/pulls?q=is%3Aopen+telegram+groupAllowFrom+store

Human Verification

• Confirmed pre-fix failure using the added test.
• Confirmed post-fix pass in targeted Telegram suites listed above.

Compatibility / Migration

• No schema/config format changes.
• Deployments that relied on implicit group authorization via DM pairing store must now add those sender IDs explicitly to groupAllowFrom (or group/topic allowFrom).

Failure Recovery

• Revert this commit to restore prior behavior.
• Operational workaround without revert: add intended senders explicitly to Telegram group allowlists.

Risks and Mitigations

• Risk: previously implicit (and unsafe) group authorization paths become blocked.
• Mitigation: behavior now aligns with documented group allowlist semantics; regression test guards against reintroduction.

Greptile Summary

Removes DM pairing store fallback from Telegram group sender authorization, preventing unauthorized group access by DM-paired users.

Key Changes:

• Replaced normalizeAllowFromWithStore with normalizeAllowFrom in group allowlist evaluation (bot-message-context.ts:198, bot/helpers.ts:52)
• Group sender checks now strictly use explicit groupAllowFrom or per-group/topic allowFrom configuration
• Added regression test validating that DM-paired sender 123456789 is blocked from group when only 222222222 is in groupAllowFrom

Security Context:
This fix mirrors the iMessage pairing-store bypass fix (commit 872079d42) and follows the same fail-closed pattern. The vulnerability allowed senders paired for DM access to trigger bot actions in groups where they should be blocked by allowlist policy.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk - it's a focused security fix that removes an unsafe authorization path.
• The changes are surgical and well-tested. The fix replaces two function calls from normalizeAllowFromWithStore (which merges DM pairing store) to normalizeAllowFrom (explicit config only), directly addressing the documented security boundary crossing. The regression test validates the fix, and the pattern matches the proven iMessage fix from commit 872079d. No logic errors or edge cases detected.
• No files require special attention

_{Last reviewed commit: 8ba4b3a}