Skip to content

fix(gateway): pairing store cannot bypass platform allowlist#23805

Open
ygd58 wants to merge 1 commit into
NousResearch:mainfrom
ygd58:fix/telegram-pairing-store-auth-bypass
Open

fix(gateway): pairing store cannot bypass platform allowlist#23805
ygd58 wants to merge 1 commit into
NousResearch:mainfrom
ygd58:fix/telegram-pairing-store-auth-bypass

Conversation

@ygd58

@ygd58 ygd58 commented May 11, 2026

Copy link
Copy Markdown
Contributor

Problem

A user who tapped Always on an approval button could permanently bypass TELEGRAM_ALLOWED_USERS via the pairing store. _is_user_authorized() checked pairing store BEFORE the allowlist, so a paired-but-not-allowed user was always authorized.

This caused the auth state inversion in #23778: attacker was paired via Always during the bypass window, continued to be authorized even after ALLOWED_USERS was fixed, while the owner (not yet paired) was correctly rejected.

Fix

If a platform allowlist is configured, verify the paired user is still in the allowlist before honoring the pairing entry. If no longer listed, revoke the pairing and deny access.

Fixes #23778 (partial - pairing store bypass)

When TELEGRAM_ALLOWED_USERS is configured, a user who tapped 'Always'
on an approval button could permanently bypass the allowlist via the
pairing store — _is_user_authorized() checked pairing store BEFORE
the allowlist, so a paired-but-not-allowed user was always authorized.

Fix: if a platform allowlist is configured, verify the paired user
is still in the allowlist before honoring the pairing store entry.
If the user is no longer listed, revoke the pairing and deny access.

This explains the auth state inversion observed in issue NousResearch#23778:
the attacker was paired via 'Always' approval during the bypass
window, which continued to authorize them even after ALLOWED_USERS
was fixed — while the owner (not yet paired) was correctly rejected.

Fixes NousResearch#23778 (partial - pairing store allowlist bypass)
@alt-glitch alt-glitch added type/security Security vulnerability or hardening comp/gateway Gateway runner, session dispatch, delivery area/auth Authentication, OAuth, credential pools P1 High — major feature broken, no workaround labels May 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/auth Authentication, OAuth, credential pools comp/gateway Gateway runner, session dispatch, delivery P1 High — major feature broken, no workaround type/security Security vulnerability or hardening

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Gateway auth bypass — unauthorized user messages processed despite "Unauthorized" log

2 participants