Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Telegram dmPolicy=open bypasses visible allowFrom allowlist and can expose bots publicly [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#73756•Fetched 2026-04-29 06:15:31
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
Hilo-HiloHilo-Hilo
Participants
clawsweeper[bot]clawsweeper[bot]Hilo-HiloHilo-Hilo
Timeline (top)
subscribed ×4commented ×1cross-referenced ×1

Telegram channel permissions can be configured in a way that looks allowlisted but is effectively public. In a real local deployment, a non-allowlisted Telegram user was able to start an OpenClaw chat/session and issue agent commands because the effective Telegram account policy was dmPolicy: "open" with allowFrom: ["*"], even though the top-level Telegram config still showed an intended single-user allowFrom allowlist.

I am intentionally omitting personal Telegram IDs, bot tokens, malicious URLs, and command payloads from this public issue.

Root Cause

Telegram channel permissions can be configured in a way that looks allowlisted but is effectively public. In a real local deployment, a non-allowlisted Telegram user was able to start an OpenClaw chat/session and issue agent commands because the effective Telegram account policy was dmPolicy: "open" with allowFrom: ["*"], even though the top-level Telegram config still showed an intended single-user allowFrom allowlist.

PR fix notes

PR #38683: Auto-heal Telegram allowFrom when dmPolicy=open

Description (problem / solution / changelog)

Draft PR Plan + Description

Title: Auto-heal allowFrom when dmPolicy="open" (Telegram) to prevent cold-start failures

Why this PR

We hit a real-world outage where the gateway needed a cold start (after VPN drop), but failed due to config validation:

  • channels.telegram.dmPolicy="open" requires channels.telegram.allowFrom to include "*".
  • Without it, config is invalid and the gateway won’t start.

This is a good invariant, but it is also a footgun because the user’s intent is unambiguous: dmPolicy=open means “allow DMs from anyone”. Requiring a second field increases outage risk.

Scope (minimal viable fix)

Implement config auto-heal before validation (or as part of doctor --fix):

  • If channels.telegram.dmPolicy === "open" and channels.telegram.allowFrom is missing/empty → set it to ["*"].
  • If channels.telegram.dmPolicy === "open" and channels.telegram.allowFrom exists but does not include "*" → auto-insert "*".
  • Apply similar logic for channels.telegram.accounts.*.dmPolicy === "open" (ensure effective allowFrom includes "*").
  • Emit a warning log once: “Auto-healed telegram allowFrom to include '*' because dmPolicy=open”.

This prevents gateway cold-start failures while still honoring the existing security model.

Where in code (what I found)

In the built dist, Telegram config schema currently enforces this strictly:

  • channels.telegram.dmPolicy="open" requires channels.telegram.allowFrom to include "*"

(Located in dist/daemon-cli.js around the TelegramConfigSchema superRefine section.)

Proposed implementation approach

Option A (preferred): normalize config before validation

Add a normalization step in the config loader / schema preprocessing:

  1. If telegram dmPolicy open and allowFrom missing, inject.
  2. Then run existing schema validation unchanged.

Pros: gateway can start even if user wrote a slightly incomplete config.

Option B: implement in openclaw doctor --fix

Doctor already repairs common issues. Add a repair rule:

  • detect the invalid combo
  • patch config and write back

Pros: no behavior change on normal gateway start; cons: still fails cold-start until doctor is run.

Given outage context, Option A is better because it prevents the failure in the first place.

Safety / security notes

  • This only triggers when user explicitly sets dmPolicy: "open".
  • It does not broaden access beyond user intent; it encodes the only consistent meaning of “open”.
  • We can add a guard: only auto-heal when allowFrom is undefined or empty, not when it contains specific IDs.

PR checklist

  • Unit test (or schema test) covering:
    • dmPolicy=open + allowFrom missing → auto-heal adds "*"
    • dmPolicy=open + allowFrom present but missing "*" → auto-heal inserts "*"
    • dmPolicy=allowlist + allowFrom missing → still error
  • Update docs: mention allowFrom auto-heal behavior
  • Changelog entry

Draft PR description (what I’d paste into GitHub)

This PR prevents gateway cold-start failures when Telegram DMs are configured as open. When channels.telegram.dmPolicy is set to "open" but allowFrom is missing, OpenClaw can currently refuse to start due to config validation. In practice the user intent is unambiguous (open means allow everyone), and requiring both fields increases outage risk.

The PR adds a small normalization step that auto-injects channels.telegram.allowFrom: ["*"] only in this specific case, then continues with existing validation. A one-time warning is logged to make the mutation visible.

Closes #38682

Changed files

  • src/config/config.legacy-config-detection.rejects-routing-allowfrom.test.ts (modified, +16/-5)
  • src/config/zod-schema.providers-core.ts (modified, +68/-0)

Code Example

{
  "channels": {
    "telegram": {
      "allowFrom": ["<trusted_telegram_user_id>"],
      "dmPolicy": "open",
      "accounts": {
        "<account_name>": {
          "dmPolicy": "open",
          "allowFrom": ["*"]
        }
      }
    }
  }
}

---

if dmPolicy is "open":
  accept the inbound DM
else:
  check allowlist
RAW_BUFFERClick to expand / collapse

Summary

Telegram channel permissions can be configured in a way that looks allowlisted but is effectively public. In a real local deployment, a non-allowlisted Telegram user was able to start an OpenClaw chat/session and issue agent commands because the effective Telegram account policy was dmPolicy: "open" with allowFrom: ["*"], even though the top-level Telegram config still showed an intended single-user allowFrom allowlist.

I am intentionally omitting personal Telegram IDs, bot tokens, malicious URLs, and command payloads from this public issue.

Observed configuration shape

A redacted version of the relevant config looked like this:

{
  "channels": {
    "telegram": {
      "allowFrom": ["<trusted_telegram_user_id>"],
      "dmPolicy": "open",
      "accounts": {
        "<account_name>": {
          "dmPolicy": "open",
          "allowFrom": ["*"]
        }
      }
    }
  }
}

The operator's expectation was that only <trusted_telegram_user_id> could send messages to the OpenClaw Telegram bot. Instead, a different Telegram account was accepted and routed into an OpenClaw session.

Actual behavior

When the Telegram account-level policy is dmPolicy: "open", the runtime appears to allow the inbound DM before the configured allowFrom allowlist meaningfully constrains access. In the installed bundle I inspected, the effective behavior was equivalent to:

if dmPolicy is "open":
  accept the inbound DM
else:
  check allowlist

This means a user can see a top-level allowFrom allowlist in config and still have the bot exposed to arbitrary Telegram users because a lower-level account policy is open and/or has a wildcard allowlist.

Expected behavior

OpenClaw should fail closed when Telegram permission layers conflict. A global or channel-level allowFrom allowlist should not be silently bypassed by an account-level dmPolicy: "open" setting.

At minimum, one of these should be true:

  • allowFrom always constrains DMs unless the user explicitly disables allowlist enforcement.
  • Account-level configs inherit the top-level Telegram allowlist by default.
  • dmPolicy: "open" plus allowFrom: ["*"] is treated as public access and flagged as a critical security finding.
  • Setup/config migration does not silently create wildcard allowFrom entries.
  • The UI/CLI clearly shows the effective policy as "public Telegram DM access" when this combination is active.
  • Enabling public Telegram DM access to an agent with shell/tool access requires an explicit high-friction confirmation.

Impact

If a Telegram bot username/link is discoverable, any Telegram user may be able to message the bot and get routed into OpenClaw despite the operator believing the bot is restricted to a specific Telegram user ID. For agents with tool execution enabled, this can become remote command execution through the assistant workflow.

Suggested fixes

  1. Change the authorization order so allowlists are applied even when dmPolicy is open, or make open impossible when an allowlist is configured.
  2. Normalize/validate Telegram account configs so wildcard account allowlists cannot coexist with a restrictive top-level allowlist without an explicit override.
  3. Add openclaw security audit coverage that marks this exact combination as critical.
  4. Add an openclaw channels status or equivalent effective-policy view that resolves global + per-account settings and reports whether each bot is public, allowlisted, or disabled.
  5. Add migration logic that removes unintended wildcard allowFrom entries when a top-level allowlist exists.

Security note

I can provide redacted local evidence privately if maintainers need it. The public issue intentionally avoids including tokens, personal account IDs, malicious payloads, or attacker-controlled URLs.

extent analysis

TL;DR

To fix the issue, change the authorization order so allowlists are applied even when dmPolicy is open, or make open impossible when an allowlist is configured.

Guidance

  • Review the Telegram configuration to ensure that dmPolicy is not set to open when an allowlist is configured, as this can bypass the allowlist constraints.
  • Consider normalizing or validating Telegram account configs to prevent wildcard account allowlists from coexisting with a restrictive top-level allowlist without an explicit override.
  • Use the suggested fixes, such as changing the authorization order or adding validation, to prevent unintended public access to the OpenClaw bot.
  • Implement additional security measures, such as an openclaw security audit or an openclaw channels status view, to detect and report critical security findings.

Example

No code snippet is provided as the issue is related to configuration and authorization logic.

Notes

The issue highlights the importance of careful configuration and validation of Telegram account settings to prevent unintended public access to the OpenClaw bot. The suggested fixes aim to address this issue by changing the authorization order or adding validation to prevent allowlist bypass.

Recommendation

Apply workaround: Change the authorization order so allowlists are applied even when dmPolicy is open, or make open impossible when an allowlist is configured. This will help prevent unintended public access to the OpenClaw bot and ensure that the allowlist constraints are enforced.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

OpenClaw should fail closed when Telegram permission layers conflict. A global or channel-level allowFrom allowlist should not be silently bypassed by an account-level dmPolicy: "open" setting.

At minimum, one of these should be true:

  • allowFrom always constrains DMs unless the user explicitly disables allowlist enforcement.
  • Account-level configs inherit the top-level Telegram allowlist by default.
  • dmPolicy: "open" plus allowFrom: ["*"] is treated as public access and flagged as a critical security finding.
  • Setup/config migration does not silently create wildcard allowFrom entries.
  • The UI/CLI clearly shows the effective policy as "public Telegram DM access" when this combination is active.
  • Enabling public Telegram DM access to an agent with shell/tool access requires an explicit high-friction confirmation.
#tokenizer error#prompt formatting#chain error#conversation history#tool integration

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Telegram dmPolicy=open bypasses visible allowFrom allowlist and can expose bots publicly [1 pull requests, 1 comments, 2 participants]