Summary

Fail closed when Telegram per-group/per-topic allowFrom override is explicitly configured but resolves to no entries. Previously this path could allow unauthorized group senders through base access checks.

Change Type

• Security fix
• Regression tests

Scope

• src/telegram/group-access.ts
• src/telegram/group-access.base-access.test.ts
• src/telegram/bot.create-telegram-bot.test.ts

Security Impact

This fixes an authorization boundary bypass in Telegram group handling. If a group/topic had an explicit allowFrom override configured as empty, base access could pass unexpectedly, allowing unauthorized users to trigger bot processing in that group context.

Repro + Verification

Repro (vulnerable behavior):

1. Configure Telegram with group-level override present and empty:
   • channels.telegram.groupPolicy = "open"
   • channels.telegram.groups["<groupId>"].allowFrom = []
2. Send a non-command group message from an arbitrary sender in that group.
3. Before fix: base access allows the message path.
4. After fix: message is blocked by group-override-unauthorized.

Targeted tests:

• pnpm exec vitest --maxWorkers=1 src/telegram/group-access.base-access.test.ts src/telegram/bot.create-telegram-bot.test.ts

Evidence

• Root cause: evaluateTelegramGroupBaseAccess delegated to isSenderAllowed for explicit overrides; Telegram sender matching helper treated empty allowlists as allowed in that call path.
• Fix: explicit override now fails closed when effectiveGroupAllow.hasEntries === false.
• Regression coverage:
  • Unit test asserting explicit empty override denies.
  • Bot-level policy case asserting empty per-group override blocks group messages.

Human Verification

• Confirmed pre-fix behavior via direct function eval returned { "allowed": true } for explicit empty override input.
• Confirmed post-fix behavior returns { "allowed": false, "reason": "group-override-unauthorized" } for the same input.
• Confirmed Telegram tests pass with regression expectations.

Compatibility / Migration

No migration required. Existing configs that intentionally set an explicit empty group/topic override now deny by default, which matches allowlist semantics.

Failure Recovery

If a group unexpectedly stops receiving messages after upgrade, set explicit sender IDs in the group/topic allowFrom override (or remove the override if open behavior is intended).

Risks and Mitigations

Risk: behavior change for configs relying on prior fail-open behavior with explicit empty overrides.
Mitigation: change is narrowly scoped to explicit override-empty condition and backed by focused tests.

Greptile Summary

Closes authorization bypass when Telegram group/topic allowFrom override is explicitly configured as empty. Previously, evaluateTelegramGroupBaseAccess delegated to isSenderAllowed, which treated empty allowlists as allowed (via isSenderIdAllowed with allowWhenEmpty: true). The fix adds an explicit fail-closed check before delegation.

• Added guard in src/telegram/group-access.ts:45-47 to deny when hasGroupAllowOverride is true but effectiveGroupAllow.hasEntries is false
• Unit test coverage confirms empty override denies, no override allows, and populated override works correctly
• Bot-level integration test verifies groupPolicy: "open" with explicit empty allowFrom override blocks messages

Confidence Score: 5/5

• Safe to merge - targeted security fix with comprehensive test coverage
• The fix correctly addresses an authorization bypass by adding a fail-closed check for explicit empty overrides. The implementation is minimal (5 lines), logically sound, and placed at the correct guard position before delegation to isSenderAllowed. Both unit and integration tests verify the fix, and the change is narrowly scoped to the vulnerable path.
• No files require special attention

_{Last reviewed commit: 3c6aa12}