Back to skill

Security audit

DeadClaw

Security checks for vulnerabilities and agentic risk

Overview

DeadClaw is a disclosed emergency stop tool, but it lets broad chat triggers and simple buttons shut down or restart OpenClaw resources without adequate authorization safeguards.

Install only if you are comfortable giving this skill authority to stop agents, containers, sessions, cron jobs, and user services. Before use, replace generic chat triggers with a namespaced admin-only command, restrict allowed senders/channels, require confirmation for kill and restore, protect cron backups, avoid broad process patterns, and treat Telegram bot tokens in phone shortcuts as sensitive long-lived credentials.

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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
Findings (5)

T01 · Skill Instruction Hijacking

Error
Location
SKILL.md:14
Finding
Destructive shutdown can be triggered by broad, unauthenticated chat keywords<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:14-25, 55-70` **Vulnerability Type**: Unauthenticated destructive command invocation **Risk Level**: High ### Vulnerable Code ```yaml trigger_keywords: - kill - KILL - dead - deadclaw - stop everything - emergency stop - "🔴" - status - restore ``` ```text ### Method 1: Message Trigger The user sends a trigger word to any connected OpenClaw channel (Telegram, WhatsApp, Discord, Slack, or any other connected channel). The following words activate DeadClaw: - `kill` or `KILL` - `dead` - `stop everything` - `emergency stop` - `deadclaw` - `🔴` When a trigger word is detected: 1. Execute `scripts/kill.sh` from the DeadClaw skill directory 2. Capture the output (process count, containers stopped, cron jobs paused, timestamp) 3. Send confirmation back to the **same channel** the trigger came from: ``` ### Technical Analysis The Skill instructs the agent to execute a destructive shutdown script when it encounters common words such as `kill`, `dead`, or a red-circle emoji in any connected channel. It does not require: - An authenticated administrator identity - A sender or channel allowlist - Exact command framing - A confirmation challenge - A nonce or replay protection - Separation between untrusted message content and authorized control commands The invoked script terminates matching processes, stops Docker containers, kills active sessions, and modifies scheduled-task state. Consequently, accepting broadly matched channel messages as authorization violates the principle that destructive actions must be tied to a strongly authenticated control plane. The same design is present in the packaged copy at `deadclaw/SKILL.md:50-67`. ### Attack Path 1. An attacker joins or compromises a Telegram, Discord, Slack, WhatsApp, or other channel connected to OpenClaw. 2. The attacker sends `kill`, `dead`, `deadclaw`, or `🔴`. 3. The agent matches the Skill trigger without verifying th ...[truncated 1043 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace ordinary-language triggers with an unambiguous administrative command, such as `/deadclaw kill <nonce>`. 2. Enforce a strict allowlist of administrator user IDs and authorized private channels before invoking any script. 3. Require a second confirmation step that summarizes the processes, containers, and scheduled tasks that will be affected. 4. Use short-lived signed requests or challenge-response authentication for phone and WebChat activation. 5. Reject commands extracted from quoted, forwarded, generated, or embedded content. 6. Rate-limit destructive requests and record authenticated actor identity, channel identity, and request ID. 7. Maintain a separately secured emergency endpoint if confirmation-free operation is required. 8. Apply the same authorization controls to `restore` because recovery starts executable workloads and scheduled tasks. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
deadclaw/scripts/kill.sh:207
Finding
Packaged kill script accepts an unrestricted environment-controlled process regex<![CDATA[ ## Vulnerability Details **File Location**: `deadclaw/scripts/kill.sh:207-260` **Vulnerability Type**: Broad process selection leading to arbitrary process termination **Risk Level**: High ### Vulnerable Code ```bash # Pattern 7: Processes matching the OPENCLAW_PROCESS_PATTERN env var # (allows users to add custom patterns for their specific setup) if [[ -n "${OPENCLAW_PROCESS_PATTERN:-}" ]]; then while IFS= read -r pid; do [[ -n "$pid" ]] && pids+=("$pid") done < <(pgrep -f "${OPENCLAW_PROCESS_PATTERN}" 2>/dev/null || true) fi # Deduplicate PIDs (guard against empty array) if [[ ${#pids[@]} -eq 0 ]]; then return fi printf '%s\n' "${pids[@]}" | sort -u ``` ```bash while IFS= read -r pid; do if [[ "$DRY_RUN" == true ]]; then log_event "DRY-RUN: Would kill PID $pid ($(ps -p "$pid" -o comm= 2>/dev/null || echo 'unknown'))" else # Send SIGTERM first (graceful), then SIGKILL after 5 seconds if still alive if kill -TERM "$pid" 2>/dev/null; then killed_pids+=("$pid") count=$((count + 1)) fi fi done <<< "$pids" # If not a dry run, wait briefly then force-kill any survivors if [[ "$DRY_RUN" == false && ${#killed_pids[@]} -gt 0 ]]; then sleep 2 for pid in "${killed_pids[@]}"; do if kill -0 "$pid" 2>/dev/null; then kill -9 "$pid" 2>/dev/null || true log_event "KILL: Force-killed stubborn process PID $pid" fi done fi ``` ### Technical Analysis `OPENCLAW_PROCESS_PATTERN` is passed directly to `pgrep -f` as a regular expression. The packaged implementation does not reject universal or excessively broad expressions such as `.*`, `.`, or other patterns that match unrelated command lines. Every matching PID is sent SIGTERM and, if still present after two seconds, SIGKILL. There is no verification that: - The executable belongs to OpenClaw - The executable path is under an expected installation directory - The process own ...[truncated 1493 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove support for arbitrary regular expressions where possible. 2. Use a fixed allowlist of executable names and canonical executable paths. 3. If custom patterns are required, reject universal and broad expressions, including `.*`, `*`, `.`, empty alternatives, anchors without literals, and patterns below a meaningful literal-length threshold. 4. Resolve each PID to `/proc/<pid>/exe` on Linux or an equivalent canonical executable path and verify it belongs to an approved OpenClaw installation. 5. Verify process ownership and expected parent/process-group relationships. 6. Explicitly exclude the current PID, parent PID, watchdog controller, shell, and OpenClaw control process unless intentionally targeted. 7. Display the complete target list and require confirmation when a custom pattern is used. 8. Add a maximum target count and abort if it is exceeded. 9. Consolidate the duplicate script trees so that validation cannot diverge between source and packaged copies. 10. Add automated tests proving that `.*`, `.`, `^`, and unrelated application names cannot select processes. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error
Location
scripts/restore.sh:229
Finding
Restore operation starts services and containers that DeadClaw did not prove it stopped<![CDATA[ ## Vulnerability Details **File Location**: `scripts/restore.sh:229-273` **Vulnerability Type**: Overbroad service and container reactivation **Risk Level**: High ### Vulnerable Code ```bash # Re-enable OS-specific services local os os=$(uname -s) if [[ "$os" == "Darwin" ]]; then for plist in ~/Library/LaunchAgents/com.openclaw.*; do [[ -f "$plist" ]] || continue launchctl load "$plist" 2>/dev/null || true log_event "Re-enabled launchd agent: $(basename "$plist")" restored_items=$((restored_items + 1)) done elif [[ "$os" == "Linux" ]]; then while IFS= read -r service; do [[ -n "$service" ]] || continue local svc_name svc_name=$(echo "$service" | awk '{print $1}') systemctl --user enable "$svc_name" 2>/dev/null || true systemctl --user start "$svc_name" 2>/dev/null || true log_event "Re-enabled systemd service: ${svc_name}" restored_items=$((restored_items + 1)) done < <(systemctl --user list-unit-files --type=service 2>/dev/null | grep -i "openclaw\|claw-agent\|clawdbot\|moltbot" | grep "disabled" || true) fi # Restart stopped Docker containers local stopped_containers stopped_containers=$(find_stopped_containers) if [[ -n "$stopped_containers" ]]; then while IFS= read -r container; do [[ -n "$container" ]] || continue docker start "$container" &>/dev/null || true log_event "Restarted Docker container: ${container}" echo "Docker container restarted: ${container}" restored_items=$((restored_items + 1)) done <<< "$stopped_containers" fi ``` The stopped-container selector used by this code is: ```bash docker ps -a --filter "name=openclaw" --filter "status=exited" --format "{{.Names}}" 2>/dev/null || true ``` ### Technical Analysis The kill operation does not create a per-event manifest recording exactly which launchd agents, systemd services, and Docker containers were active and changed by DeadCl ...[truncated 1899 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. During each kill event, create a protected manifest containing: - Unique event ID - Exact service unit names and canonical unit paths - Exact launchd plist paths and labels - Exact Docker container IDs rather than mutable names - Pre-kill enabled/running state - Timestamp and integrity checksum 2. Restore only resources recorded as changed by the selected event. 3. Do not enable a service that was disabled before the kill event. 4. Do not start a container that was exited before the kill event. 5. Validate ownership and canonical paths for service and launchd definitions before loading them. 6. Show the exact manifest to the user and require item-level confirmation. 7. Reject missing, malformed, writable-by-others, or integrity-invalid manifests. 8. Avoid broad substring matching for recovery authorization. 9. Record command failures accurately instead of incrementing `restored_items` after commands hidden behind `|| true`. 10. Provide separate flags for cron, services, containers, gateway, and watchdog restoration. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/kill.sh:273
Finding
Full crontab is backed up with inherited permissions and later restored wholesale<![CDATA[ ## Vulnerability Details **File Location**: `scripts/kill.sh:273-292` and `scripts/restore.sh:211-225` **Vulnerability Type**: Sensitive local data exposure and unsafe state replacement **Risk Level**: Medium ### Vulnerable Code ```bash # Create backup directory if it doesn't exist mkdir -p "$BACKUP_DIR" # Back up the current crontab before touching anything local backup_file="${BACKUP_DIR}/deadclaw-crontab-backup-$(date +%Y%m%d-%H%M%S).txt" if crontab -l &>/dev/null; then crontab -l > "$backup_file" 2>/dev/null || true log_event "CRON: Crontab backed up to ${backup_file}" # Count OpenClaw-related cron entries cron_count=$(grep -c -i "openclaw\|claw-agent\|clawdbot\|moltbot" "$backup_file" 2>/dev/null || true) cron_count=${cron_count:-0} if [[ "$DRY_RUN" == true ]]; then log_event "DRY-RUN: Would remove ${cron_count} OpenClaw cron entries" else crontab -l 2>/dev/null | grep -v -i "openclaw\|claw-agent\|clawdbot\|moltbot" | crontab - 2>/dev/null || true log_event "CRON: ${cron_count} OpenClaw cron entries removed" fi fi ``` ```bash # Restore crontab if [[ -n "$backup_file" && -f "$backup_file" ]]; then crontab "$backup_file" 2>/dev/null if [[ $? -eq 0 ]]; then log_event "Crontab restored from ${backup_file}" echo "Crontab restored." restored_items=$((restored_items + 1)) else log_event "Failed to restore crontab from ${backup_file}" echo "Warning: Failed to restore crontab." fi fi ``` ### Technical Analysis The script creates the backup directory and backup file without setting a restrictive `umask` or explicit permissions. The resulting access mode depends on the caller's environment. Crontabs commonly contain: - API tokens - Passwords embedded in URLs - Cloud credentials - Environment variables - Sensitive filesystem paths - Operational command details The complete crontab is copied even though the shutdown operation only remove ...[truncated 1502 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Set `umask 077` before creating logs, PID files, manifests, and backups. 2. Create the backup directory with mode `0700` and each backup with mode `0600`. 3. Validate that the backup directory is owned by the current user and is not a symbolic link. 4. Back up only entries that DeadClaw will remove, while recording sufficient line and ordering information for safe recovery. 5. Record a hash of the unaffected crontab state at kill time. 6. During restore, compare the current crontab with the saved baseline and present conflicts. 7. Merge only entries removed by the selected kill event instead of replacing the complete current crontab. 8. Avoid storing secrets directly in crontab entries; reference protected credential files or a secret manager. 9. Apply retention limits and securely remove obsolete backups. 10. Ensure dry-run mode does not create unnecessary backup artifacts. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
docs/android-widget-guide.md:40
Finding
Android shortcut instructions place a long-lived Telegram bot token in third-party app configuration<![CDATA[ ## Vulnerability Details **File Location**: `docs/android-widget-guide.md:40-48, 96-105` **Vulnerability Type**: Insecure storage of an authentication credential **Risk Level**: Medium ### Vulnerable Code ```text ### A3: Add an HTTP Request Action 1. In the task editor, tap the **+** button to add an action 2. Tap **Net** 3. Tap **HTTP Request** 4. Fill in: - **Method**: POST - **URL**: `https://api.telegram.org/botYOUR_BOT_TOKEN_HERE/sendMessage` (Replace `YOUR_BOT_TOKEN_HERE` with your actual bot token) - **Content Type**: `application/json` - **Body**: `{"chat_id": "YOUR_CHAT_ID_HERE", "text": "deadclaw"}` (Replace `YOUR_CHAT_ID_HERE` with your numeric chat ID) ``` ```text ### B3: Configure the Basics 1. **Name**: DeadClaw 2. **Description**: Emergency kill switch for OpenClaw agents 3. **Method**: POST 4. **URL**: `https://api.telegram.org/botYOUR_BOT_TOKEN_HERE/sendMessage` Replace `YOUR_BOT_TOKEN_HERE` with your actual Telegram bot token. You got this from BotFather when you created your bot. It looks like `7123456789:AAHxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`. ``` ### Technical Analysis The guide instructs users to embed a long-lived Telegram bot token directly into a URL stored by Tasker or HTTP Shortcuts. Although HTTPS protects the request in transit, it does not protect the credential at rest in: - Application configuration - Exported Tasker tasks or shortcut files - Device backups - Debug or request logs - Screenshots and support captures - Shared automation profiles - Clipboard history during setup Telegram's API design requires the bot token in the URL path, but storing that URL in a general-purpose automation profile enlarges the credential exposure surface. The token controls the bot and can be used independently of the legitimate phone. This instruction is duplicated at `deadclaw/docs/android-widget-guide.md`. ### Attack Path 1. The user follows the guide and stores the bot token in a Tasker or HTTP Shor ...[truncated 1297 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Prefer a minimal authenticated relay service so the phone stores a narrowly scoped, revocable DeadClaw credential rather than the full Telegram bot token. 2. Restrict the relay to one operation, one destination, and a short validity period. 3. Require signed requests, timestamps, nonces, and replay prevention. 4. If direct Telegram access is retained, use secure-variable or encrypted-secret facilities offered by the automation application. 5. Warn users that exported profiles, backups, logs, screenshots, and clipboard contents may disclose the token. 6. Instruct users never to share shortcut configurations containing credentials. 7. Document immediate BotFather token revocation and rotation procedures. 8. Restrict the Telegram bot to approved private chats and verify administrator user IDs before processing DeadClaw commands. 9. Avoid placing the token in user-visible success or error output. 10. Add periodic token rotation and device-loss response guidance. ]]>
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • YARA SignaturesMalware Match, Webshell Match, Cryptominer Match
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Findings (125)

YARA rule 'backdoor_persistence': Backdoor persistence with malicious payloads (shell commands, SSH key injection, hidden root users) [malware]

High
Category
YARA Match
Content
thing: stops everything. Designed for anyone to set up in under five minutes and activate from their phone lock screen.

---

## The Four Scripts

### `kill.sh` — The Panic Button

Shuts everything down immediately:

- Kills all OpenClaw agent processes (SIGTERM, then SIGKILL for anything stubborn)
- Stops all OpenClaw Docker containers (kills sessions inside first, then stops)
- Backs up your crontab to a timestamped file, then removes OpenClaw cron entries
- Pauses launchd agents (macOS) or systemd services (Linux)
- Logs everything to `deadclaw.log`
- Sends confirmation back to the triggering channel

```bash
bash scripts/kill.sh              # Kill everything
bash scripts/kill.sh --dry-run    # See what WOULD happen without killing
```

### `status.sh` — The Dashboard

Shows what's running. Read-only, safe to run anytime.

```bash
bash scripts/status.sh            # Human-readable report
bash scripts/status.sh --json     # Machine-readable output
```

Example output:

```
Dead
Confidence
75% confidence
Finding
YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).

Vague Triggers

High
Confidence
97% confidence
Finding
The documented trigger phrases include very short and common terms like "kill" and "dead," which are prone to accidental activation in normal conversation or message history replay. Because the action halts agents, stops containers, and alters scheduling, unintended triggering can cause immediate service interruption and operational disruption.

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding
The code largely matches the declared core kill-switch behavior: stopping agents/processes, pausing scheduled jobs, killing sessions, logging, and handling Docker/native installs. However, the description claims additional major capabilities not present in this code chunk, especially the background watchdog with policy-based auto-kill conditions and explicit trigger mechanisms such as message/button/shortcut handling. This script only accepts CLI flags/environment context for logging and executes the kill sequence when run; it does not itself implement those trigger surfaces or the watchdog detection logic. Because those are substantial declared behaviors rather than minor supporting details, this is a description/behavior mismatch for the supplied code chunk.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The declared description is for an emergency stop/kill-switch capability that shuts down agents and automatically terminates unsafe activity. The supplied code does the opposite operationally: it is a recovery script intended to bring services back online after a kill event. Its primary purpose is restoration, not halting. It accesses and modifies scheduling/service state by restoring crontab entries, enabling services, starting containers, and restarting gateway/watchdog processes—capabilities not represented in the description. While logging is mentioned in both, that overlap is incidental and does not align the primary behavior.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The declared description promises a kill switch with active intervention capabilities: stopping agents, pausing scheduled jobs, killing sessions, logging shutdown actions, and automatically terminating agents under unsafe conditions. The supplied code does none of that. It is a status/health report script that inspects running processes and Docker containers, reads token metrics, checks whether a watchdog process appears active, and prints human-readable or JSON status. Its own header explicitly describes it as a health report and says it is triggered by a user sending "status." This is a material description-behavior mismatch because the code’s primary purpose is observational monitoring, not emergency shutdown or enforcement.

Tp4

High
Category
MCP Tool Poisoning
Confidence
96% confidence
Finding
The code substantially matches the watchdog portion of the description: it runs a background monitor, checks runtime, token usage, network destinations, and file writes, logs events, and auto-triggers a kill action. However, the declared purpose presents the skill primarily as a full emergency kill switch that can be manually triggered through several user-facing mechanisms and that directly halts agents, pauses jobs, and kills sessions. None of those manual trigger paths appear in this code chunk, and the actual stopping behavior is not implemented here but handed off to an external kill.sh script. Because the chunk's concrete behavior is narrower than the declared end-user description and omits key declared capabilities, this is a description/behavior mismatch.

Tp4

High
Category
MCP Tool Poisoning
Confidence
92% confidence
Finding
The code largely matches the core kill-switch behavior: it kills OpenClaw processes, stops Docker containers, pauses scheduled jobs, kills sessions, and logs the incident. However, the declared description materially overstates capabilities not present in this code chunk, especially the watchdog that detects and auto-kills on specific safety conditions. The script only stops a separate `watchdog.sh`; it does not implement watchdog monitoring itself. It also does not implement the declared trigger surfaces (message/button/shortcut) in this chunk. In the other direction, the code performs some capabilities not clearly declared, notably sending a confirmation message back to a channel and disabling/stopping systemd or launchd services in addition to editing cron. Overall, this is a description/behavior mismatch because important declared capabilities are absent from the provided code and there are a few undeclared operational behaviors.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The declared description centers on an emergency stop/kill-switch capability with watchdog-based automatic shutdown behavior. The supplied code does the opposite operationally: it is a recovery script intended to bring systems back online after a kill event. Its primary actions are restoration and restart of cron jobs, services, containers, and the gateway. Although it belongs to the same DeadClaw skill family and references post-kill safety, the actual behavior of this code chunk is materially different from the declared purpose, so this is a clear description-behavior mismatch.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The declared description presents a safety-critical kill switch whose main function is to immediately stop agents and enforce automatic shutdowns under dangerous conditions. The supplied code does none of that. It is a status.sh script that collects and prints operational status for native processes and Docker containers, reads token metrics, checks whether a watchdog PID appears active, and emits warnings when thresholds are being approached. It is explicitly read-only (`--dry-run` is noted as identical because status is already read-only), and there are no commands to terminate processes, pause jobs, kill sessions, or enforce watchdog actions. The trigger described in comments is also different: the script is meant for a 'status' request, not an emergency stop. This is a clear description-behavior mismatch with a materially different primary purpose.

Tp4

High
Category
MCP Tool Poisoning
Confidence
96% confidence
Finding
The code aligns with the watchdog portion of the description: it monitors runtime, token usage, network connections, and file writes, logs events, and auto-triggers a kill action. However, the declared purpose presents a broader skill centered on an emergency kill switch with manual trigger paths and direct stoppage of agents/jobs/sessions. None of those manual trigger mechanisms are implemented in this code chunk, and the actual stopping behavior is delegated to another script not shown here. Because the provided code covers only part of the declared functionality and omits key advertised trigger methods and shutdown actions, this is a material description-behavior mismatch.

Vague Triggers

High
Confidence
98% confidence
Finding
The trigger list includes broad terms like 'kill', 'dead', 'status', and 'restore', which are common in ordinary conversation and likely to collide with unrelated user messages. In a skill designed to halt agents, stop containers, and alter scheduling, accidental activation could cause immediate denial of service and unsafe operational disruption.

Vague Triggers

High
Confidence
99% confidence
Finding
The keyword list is dangerously collision-prone, especially because it contains generic operational words and even emoji that may appear in normal chat. Given the skill's destructive authority over processes, jobs, containers, and sessions, an attacker or even an innocent user could trigger a platform-wide shutdown with trivial input.

Vague Triggers

High
Confidence
99% confidence
Finding
Single-word message triggers without exclusion rules, authentication, or confirmation create a highly exploitable kill-switch interface. Any user who can send messages on a connected channel—or any malicious prompt/content that causes those words to appear—could induce mass shutdown of agents, session termination, and scheduler interruption.

Vague Triggers

High
Confidence
98% confidence
Finding
The documented trigger set includes very broad, common words like "kill", "dead", and "stop everything", and states they work from any connected channel. That creates a realistic risk of accidental or spoofed activation through ordinary conversation, forwarded messages, or untrusted participants, causing a full shutdown of running agents and scheduled jobs.

Missing User Warnings

High
Confidence
95% confidence
Finding
The installation and setup text presents message-triggered remote kill capability as immediately available, but does not clearly warn users that installing the skill exposes a destructive control path across connected messaging channels. That omission can cause operators to enable a remotely invocable kill switch without understanding the attack surface or accidental-trigger risk.

Vague Triggers

High
Confidence
99% confidence
Finding
The trigger list includes extremely common terms such as `kill`, `dead`, and `status`, which can appear in ordinary conversation and could unintentionally invoke destructive actions. Because this skill is designed to halt agents, pause jobs, and kill sessions across connected channels, accidental or spoofed activation could cause widespread denial of service and operational disruption.

Hidden Instructions

High
Category
Prompt Injection
Content
(Replace `YOUR_CHAT_ID_HERE` with your numeric chat ID)
5. Tap the back arrow to save

<!-- SCREENSHOT_PLACEHOLDER: tasker-http-request.png -->

### A4: Test the Task
Confidence
70% confidence
Finding
Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.

Hidden Instructions

High
Category
Prompt Injection
Content
Open the Google Play Store, search for **HTTP Shortcuts** (by Roland Meyer), and install it. It's free.

<!-- SCREENSHOT_PLACEHOLDER: http-shortcuts-playstore.png -->

### B2: Create a New Shortcut
Confidence
70% confidence
Finding
Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.

Hidden Instructions

High
Category
Prompt Injection
Content
```
   Replace `YOUR_CHAT_ID_HERE` with your numeric Telegram chat ID.

<!-- SCREENSHOT_PLACEHOLDER: http-shortcuts-body.png -->

### B5: Set the Icon
Confidence
70% confidence
Finding
Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.

Vague Triggers

High
Confidence
97% confidence
Finding
The documented message trigger is the single word "kill" sent to any connected channel, which is highly collision-prone in normal conversation and can be invoked accidentally or by anyone able to post in those channels. In a kill-switch skill, unintended activation causes immediate denial of service by terminating agents, pausing jobs, and killing sessions, making the broad trigger especially dangerous in this context.

Hidden Instructions

High
Category
Prompt Injection
Content
If you can't find it, swipe down on your home screen to open search, then type "Shortcuts" and tap it.

<!-- SCREENSHOT_PLACEHOLDER: shortcuts-app-icon.png -->

---
Confidence
70% confidence
Finding
Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.

Hidden Instructions

High
Category
Prompt Injection
Content
- Choose **Text** as the type
   - Enter the key name and value

<!-- SCREENSHOT_PLACEHOLDER: configure-url-action.png -->

---
Confidence
70% confidence
Finding
Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.

Context-Inappropriate Capability

High
Confidence
95% confidence
Finding
The phrase "from a friend's phone, from anywhere" implies that a destructive stop action may be triggered remotely without strong proof of identity or device binding. For a kill-switch skill, unauthenticated or weakly authenticated remote invocation creates a direct denial-of-service path where any party able to send the trigger can halt agents, pause jobs, and disrupt operations.

Vague Triggers

High
Confidence
97% confidence
Finding
Using the single word "kill" as a message trigger is dangerously broad and likely to collide with normal conversation, jokes, quoted text, or incident discussion. In a multi-channel environment, accidental activation could stop all running agents and pause scheduled tasks, producing self-inflicted denial of service.

Missing User Warnings

High
Confidence
94% confidence
Finding
The documentation presents message-triggered stopping across connected channels as convenient, but does not clearly warn that this can halt agents and pause cron jobs through chat interfaces that may be broadly accessible or insufficiently trusted. Missing safety warnings around destructive remote controls increase the likelihood of insecure deployment and accidental or unauthorized service disruption.

Static analysis

No suspicious patterns detected.