Security: Telegram bot hands device control to any chat when the owner line is missing #85

Who is this for?

Personal

Company name

NA

Showing your name

• AutoCua may show our company name on its website as a team that trusts it.

Mode

computer use

How it was started

Straight from the terminal

What happened

The Telegram remote-control service decides whether a chat may control the device by comparing it with the owner chat id stored in AutoCua_data/api_key/api_key.txt (TELEGRAM_OWNER_CHAT_ID=). When that line is absent or unparsable, _resolve_owner_chat_id() returns None, and _is_owner_chat() treats None as "no owner has claimed the bot yet": it writes the sender's chat id to the key file and returns True. The startup hook does the same with Telegram's latest pending update.

The owner line can be lost by the product's own non-atomic key-file rewrite: _set_key_in_file() at AutoCua/mac/remote_connection/telegram/service.py:121-150 opens the file with open(path, "w") (truncating it) and writes the lines back one by one. A crash, a full disk or a concurrent update between the token line and the owner line leaves a valid key file with the owner line missing. _resolve_owner_chat_id() at :153-162 then returns None, and _is_owner_chat() at :174-191 authorizes the sender and persists the new owner. _post_init() at :369-400 and _discover_owner_from_updates() at :350-366 additionally adopt the latest pending Telegram update when no owner is stored.

Steps to reproduce: run the service against a Bot API test endpoint that serves getMe, getUpdates and sendMessage. Control: with TELEGRAM_OWNER_CHAT_ID=111 present, an update from chat 666 gets no reply and only chat 111 receives the control menu. Fault: remove the owner line (an interrupted _set_key_in_file leaves exactly this file), restart the service with the same pending update from 666; the service replies with the owner menu, dispatches the task (📝 Running: ...) and writes TELEGRAM_OWNER_CHAT_ID=666 into the key file. A second chat is then ignored.

The owner id is the only authorization between a Telegram chat and the device, and the bot is reachable by any Telegram user who knows its username. The token is not involved in the decision, and nothing downstream re-checks the claimant.

What you expected

Only the paired owner chat should control the bot. If the owner line is missing or unreadable, that should be treated as a configuration error: the service should refuse to claim from message handlers and require an explicit operator pairing step, instead of interpreting the fault as a first run.

Model and provider: this report does not depend on the model. The reproduction used a local Bot API test endpoint for Telegram; the bot's provider entry was the default OpenRouter one, and the ownership decision happens before any model call.

The repository has no SECURITY.md and no private vulnerability reporting path, so this is filed as a regular bug report rather than a private advisory.

Conversation

The reproduction is a Bot API transcript and a key-file diff, not a chat conversation; sensitive data is not included.

• Control transcript (owner line present): 666 → /start produces no outgoing sendMessage; 111 → /start produces the 🟢 AutoCua online at ..., provider picker and control menu.
• Fault transcript (owner line removed): 666 → /start produces the same 🟢 AutoCua online at ..., provider picker and 📝 Running: <task>; the key file gains TELEGRAM_OWNER_CHAT_ID=666.
• Key-file diff: before TELEGRAM_BOT_TOKEN=...\nTELEGRAM_OWNER_CHAT_ID=111\n; after the fault TELEGRAM_BOT_TOKEN=...\nTELEGRAM_OWNER_CHAT_ID=666\n.