Back to skill

Security audit

Telegram Rich Messages

Security checks for vulnerabilities and agentic risk

Overview

The skill is a mostly coherent Telegram messaging guide, but its reusable examples include a fixed Telegram recipient and local file upload without enough safeguards.

Install only if you are comfortable reviewing and adapting the examples. Replace every hard-coded Telegram target with the authenticated active chat, send only files intentionally created or selected for the current task, and require confirmation before uploads or deletions involving sensitive content.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T09 · Insecure Skill Coding Practices

Note
Location
references/interactive-ui.md:9
Finding
Hard-Coded Telegram Recipient in Interactive Message Example## Vulnerability Details **File Location**: `references/interactive-ui.md:9-25` **Vulnerability Type**: Hard-coded external recipient identifier **Risk Level**: Low ### Vulnerable Code ```json { "action": "send", "channel": "telegram", "target": "telegram:2136878064", "message": "What would you like to do next?", "buttons": [ [ { "text": "🎨 Start Creation", "callback_data": "start_apollo" }, { "text": "📧 Check Mail", "callback_data": "check_mail" } ], [ { "text": "⚙️ Settings", "callback_data": "show_settings" }, { "text": "🌐 Visit Website", "url": "https://example.com" } ] ] } ``` ### Technical Analysis The actionable example contains the concrete Telegram recipient identifier `telegram:2136878064` instead of an unmistakable placeholder or a value dynamically obtained from the active conversation. An agent or operator copying the example literally may send a message to this account rather than to the intended user. The documentation does not explicitly instruct the agent to contact this recipient, so there is no evidence of intentional data exfiltration. Nevertheless, embedding a real-looking destination in a directly reusable tool call violates safe example-design practices and creates an accidental external-disclosure channel. ### Attack Path 1. An agent loads this skill while handling a Telegram interaction. 2. The agent consults the inline-button example. 3. The agent reproduces the documented tool call without replacing the `target` field. 4. OpenClaw invokes the Telegram `message` tool using the hard-coded recipient. 5. The message and its interactive controls are delivered to `telegram:2136878064` rather than the active user. Exploitation requires the example to be copied literally and the configured Telegram bot to be permitted to communicate with that recipient. ### Impact Assessment No additional system privileges are ...[truncated 379 chars]
Remediation
## Remediation Suggestions - Replace the concrete recipient with an unmistakable placeholder, such as `"target": "telegram:<ACTIVE_CHAT_ID>"`. - State explicitly that the target must be derived from the authenticated active conversation and must never be copied from documentation. - Validate that the resolved recipient matches the current conversation before sending. - For generated examples, omit `target` entirely when the tool can infer it safely from session context. - Add a pre-send confirmation when content is sensitive or when the resolved destination differs from the active chat. - Add documentation linting that rejects concrete Telegram identifiers in reusable examples.

T09 · Insecure Skill Coding Practices

Warning
Location
references/media-and-actions.md:8
Finding
Hard-Coded Telegram Recipient in Local File Transfer Example## Vulnerability Details **File Location**: `references/media-and-actions.md:8-15` **Vulnerability Type**: Hard-coded external recipient in a local file transfer operation **Risk Level**: Medium ### Vulnerable Code ```json { "action": "send", "channel": "telegram", "target": "telegram:2136878064", "message": "Here is the PDF report.", "media": "/tmp/report.pdf" } ``` ### Technical Analysis This reusable example combines a concrete Telegram recipient with a local filesystem media path. If followed literally, the Telegram tool may read `/tmp/report.pdf` and transmit it to `telegram:2136878064`. A hard-coded destination is particularly unsafe in a file-transfer example because the transferred document may contain confidential reports, personal information, credentials, internal business data, or other sensitive material. The example does not require recipient verification, user confirmation, path validation, or a sensitivity check before transmission. There is no evidence that the project creates `/tmp/report.pdf`, intentionally collects sensitive files, or deliberately directs agents to exfiltrate data. The risk arises from accidental literal reuse of the documented call. ### Attack Path 1. A report or another document exists at `/tmp/report.pdf`. 2. An agent uses the skill documentation to send that file through Telegram. 3. The agent copies the example without substituting the intended chat identifier. 4. The `message` tool reads the local file using its existing filesystem access. 5. The tool uploads the file to the hard-coded Telegram recipient. 6. The unintended recipient can access any data contained in the transmitted document. Exploitation requires a readable file at the specified path, literal reuse of the example, and sufficient bot permissions to send media to the recipient. ### Impact Assessment This issue does not grant new filesystem or Telegram privileges. It can, however, ...[truncated 361 chars]
Remediation
## Remediation Suggestions - Replace the concrete destination with `"target": "telegram:<VERIFIED_CHAT_ID>"`. - Resolve the recipient from the authenticated active conversation rather than from static documentation. - Require explicit confirmation that displays both the resolved recipient and the file name before uploading local media. - Verify that the selected path is an expected regular file within an approved export directory. - Reject symbolic links, unexpected file types, and paths outside the permitted media directory. - Apply file-size limits and scan documents for secrets or sensitive metadata before transmission. - Avoid predictable shared temporary paths where another process could replace the file between validation and upload. - Add automated checks that prevent concrete account identifiers from being committed in tool-call examples.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (2)

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The skill explicitly instructs users to send files from the agent's local filesystem via a path like /tmp/report.pdf, but provides no warning or constraints around local file access. In an agent setting, this can normalize or enable exfiltration of sensitive host data, especially if a prompt or workflow causes the agent to reference arbitrary local paths rather than user-provided files only.

Missing User Warnings

Low
Confidence
83% confidence
Finding
The documentation recommends delete actions for sensitive or temporary messages without warning that deletion is destructive and may remove information the user wanted preserved. While lower severity than file exfiltration, this can still cause loss of auditability, confusion, or unintended destruction of useful context in conversations.

Static analysis

No suspicious patterns detected.