T03 · Remote Payload Retrieval and Execution
- Location
setup.sh:67- Finding
Unsafe Remote Installer Execution Recommendation
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This fall-detection skill is coherent overall, but it needs Review because it can expose sensitive camera details and use under-disclosed credentials or third-party services.
Review this carefully before installing. Only run it with camera owners' consent, avoid putting camera passwords directly inside RTSP URLs if possible, keep config.json and logs private, and disable saved clips if you do not need them. Be aware that alarm clips are sent to the KamiClaw cloud API, configured notifications send fall-event details to Feishu/Telegram/Discord, and the current Feishu fallback can upload an image to sm.ms. Do not rely on the installer to preserve an existing conda environment named kami-fall.
setup.sh:67Unsafe Remote Installer Execution Recommendation
feishu_notifier.py:27Undisclosed Upload of a Local Image to a Public Anonymous Host
fall_detect_cloud_skill.py:553Camera Credentials Disclosed Through Logs and Standard Output
telegram_notifier.py:168Telegram Notifier Reads Agent-Wide OpenClaw Credentials Outside the Skill Configuration
requirements.txt:1Mutable Unpinned Dependencies Installed Without Integrity Verification
setup.sh:24Installer Automatically Deletes an Existing Conda Environment
YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).
"""
Telegram Notification Module for Fall Detection
Sends alarm notifications to Telegram using Bot API.
Supports:
- Direct chat_id configuration
- Webhook-style direct API calls
"""
import json
import logging
import os
import time
from pathlib import Path
from typing import Optional, Dict, Any
logger = logging.getLogger(__name__)
# Telegram API endpoint
TELEGRAM_API_URL = "https://api.telegram.org/bot"
class TelegramNotifier:
"""Send fall alarm notifications to Telegram."""
def __init__(self, bot_token: str):
"""
Initialize Telegram notifier.
Args:
bot_token: Telegram bot token (e.g., 123456:ABC-DEF1234...)
"""
self.bot_token = bot_token
self.api_url = f"{TELEGRAM_API_URL}{bot_token}"
def send_text_message(self, chat_id: str, text: str) -> bool:
"""
Send a text message to a Telegram chat.
Args:
chat_id: Telegram chat ID (numeric strin
This pattern attempts to override system instructions or ignore safety constraints. Without LLM analysis, manual review is recommended.
config.json:{
If the implementation primarily reads Telegram credentials, formats messages, and sends alerts without clear RTSP handling or KamiClaw API use, then the skill's declared purpose is misleading and the real behavior centers on external messaging. In the context of a surveillance-oriented skill that handles RTSP URLs and API keys, hidden messaging-centric behavior raises the risk of data leakage and unauthorized outbound communication.
If the implementation primarily reads Telegram credentials, formats messages, and sends alerts without clear RTSP handling or KamiClaw API use, then the skill's declared purpose is misleading and the real behavior centers on external messaging. In the context of a surveillance-oriented skill that handles RTSP URLs and API keys, hidden messaging-centric behavior raises the risk of data leakage and unauthorized outbound communication.
If the implementation primarily reads Telegram credentials, formats messages, and sends alerts without clear RTSP handling or KamiClaw API use, then the skill's declared purpose is misleading and the real behavior centers on external messaging. In the context of a surveillance-oriented skill that handles RTSP URLs and API keys, hidden messaging-centric behavior raises the risk of data leakage and unauthorized outbound communication.
If the implementation primarily reads Telegram credentials, formats messages, and sends alerts without clear RTSP handling or KamiClaw API use, then the skill's declared purpose is misleading and the real behavior centers on external messaging. In the context of a surveillance-oriented skill that handles RTSP URLs and API keys, hidden messaging-centric behavior raises the risk of data leakage and unauthorized outbound communication.
The code silently uploads local image data to a third-party anonymous image host without warning the user. Because this skill is for fall detection, the media likely contains sensitive surveillance imagery of vulnerable individuals, making undisclosed external transmission especially harmful.
Uploading posture images from a fall-detection system to a public anonymous image host is unjustified and dangerous. The skill handles potentially highly sensitive elder-care imagery, so external publication to a public URL can expose private health-related events, home interiors, and personally identifiable information.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
self._token_cache: Dict[str, Any] = {}
def _get_tenant_token(self) -> str:
"""Get or refresh tenant access token."""
now = time.time()
# Check cache
The script prints guidance telling users to run 'curl https://pyenv.run | bash', which is a classic unsafe pattern because it fetches and immediately executes remote code without verification. Even though the setup script does not execute the command itself, embedding this installation advice in the skill materially increases the chance that users will run untrusted network-delivered code during setup.
echo " conda activate kami-fall"
echo ""
echo " 🐍 pyenv (Linux/macOS - user-level install):"
echo " curl https://pyenv.run | bash"
echo " pyenv install 3.10"
echo " pyenv global 3.10"
echo ""
The manifest and top-level README description present the skill as a cloud fall detector with optional Feishu alarm notifications. However, the README later documents Telegram and Discord notification channels and even optional two-way communication/gateway use, which materially broadens the skill beyond the stated notification scope.
The README documents saving alarm clips and structured logs containing monitoring events without warning that these artifacts may contain sensitive surveillance data. In an elderly-care setting, local retention of clips, timestamps, camera names, and event details can materially increase privacy risk if the host is shared, backed up, or later compromised.
The README states that RTSP-derived clips are uploaded to a cloud API for analysis but does not clearly warn users that potentially sensitive in-home video is transmitted off-device. In the context of elderly-care monitoring, this omission is significant because users may not appreciate the privacy, consent, and compliance implications of sending footage to a third party.
The README encourages supplying API keys via config files, CLI arguments, and environment variables, and even shows realistic secret formats. CLI arguments can be exposed via process listings and shell history, and config files are often accidentally committed or shared, making credential leakage more likely.
The documentation introduces optional Telegram/Discord two-way communication features that are not necessary for one-way fall-alert delivery. Unneeded interactive channels expand the skill's trust boundary, create additional credential exposure, and may permit remote command/control paths if corresponding gateway services are enabled.
The skill declares capabilities that include environment access, file read/write, network access, and shell execution, but provides no explicit tool-scope or permissions declaration. That makes it harder for a host agent or reviewer to constrain execution, increasing the risk of over-privileged operation against local files, secrets, and external services.
Broad triggers like 'home assistant' and 'smart home' are likely to match ordinary conversation and invoke the skill unexpectedly. Because this skill can collect RTSP URLs, write config files, and initiate continuous monitoring with networked notifications, accidental activation could lead to unintended handling of sensitive camera and credential data.
The setup flow directs the agent to write configuration, optionally run a command, and run the skill, while also discouraging manual review by telling the user never to edit config.json. This is risky because it encourages autonomous execution of a networked, file-writing, continuous-monitoring skill that handles secrets and camera endpoints without an explicit user confirmation checkpoint.
7. Optionally run `python fall_detect_cloud_skill.py --list_cameras` to confirm the resolved camera list.
8. Run the skill.
**Never run with an empty `api_key`. Never run with `cameras` empty. When the user has multiple cameras, never accept missing/duplicate names — re-prompt until each camera has a unique label. Never ask the user to manually edit config.json.**
---
The skill manifest describes detecting falls from RTSP streams via the KamiClaw cloud API, but this file adds a separate outbound integration layer to Discord, including webhooks, bot API messaging, test messaging, and media attachment support. While notifications may be related operationally, Discord alerting is a distinct capability not reflected in the manifest description, which frames the skill as cloud fall detection rather than external messaging integration.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
if footer:
payload["embeds"][0]["footer"] = {"text": footer}
resp = requests.post(
self.webhook_url,
json=payload,
timeout=10
This code transmits fall-event data to Discord, a third-party service, without any built-in disclosure, consent check, or privacy guardrails. In this skill context, alerts may contain sensitive monitoring information about vulnerable individuals, making undisclosed external sharing materially risky.
This path uploads a local posture image file to Discord without explicit warning or consent controls. In a fall-detection skill, images can expose highly sensitive in-home scenes and health-related information, so silent transmission to an external platform significantly increases privacy impact.
The file explicitly introduces 'Discord Bot API Support (Two-Way Communication)' and stores bot credentials to send messages via channel APIs. For a skill whose stated purpose is cloud fall detection, webhook-based alert delivery is easier to justify, but adding bot-token-based API access and describing it as two-way communication expands into interactive chat integration that the manifest does not claim.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
if footer:
payload["embeds"][0]["footer"] = {"text": footer}
resp = requests.post(
f"{self.api_base}/channels/{self.channel_id}/messages",
headers=self.headers,
json=payload,
The Bot API notification flow sends alarm details to Discord channels without any explicit privacy notice or consent mechanism. Because the data concerns fall detection and home monitoring, unintended sharing to a channel can expose sensitive personal and situational information.
No suspicious patterns detected.