Back to skill

Security audit

Heartrate

Security checks for vulnerabilities and agentic risk

Overview

This heart-rate skill appears local-only and not malicious, but its health-data storage and advertised features are under-scoped enough that users should review it before installing.

Install only if you are comfortable with a simple, local, plaintext health log in ~/.local/share/heartrate. Review file permissions on that directory, avoid entering sensitive notes on shared machines, and be aware that the advertised analytics/export behavior does not appear to work as described.

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 (1)

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/script.sh:7
Finding

Sensitive Health Records Stored Without Enforced File Permissions

Content
View full analysis

Vulnerability Details

File Location: scripts/script.sh:7-8, scripts/script.sh:62-94, and scripts/script.sh:130-300
Vulnerability Type: Plaintext sensitive-data storage with insufficient access-control enforcement
Risk Level: Medium

Vulnerable Code

bash
DATA_DIR="${HOME}/.local/share/heartrate"
mkdir -p "$DATA_DIR"

_log() { echo "$(date '+%m-%d %H:%M') $1: $2" >> "$DATA_DIR/history.log"; }

The export function also creates plaintext reports without explicitly restricting their permissions:

bash
_export() {
    local fmt="${1:-json}"
    local out="$DATA_DIR/export.$fmt"
    case "$fmt" in
        json)
            echo "[" > "$out"
            local first=1
            for f in "$DATA_DIR"/*.log; do
                [ -f "$f" ] || continue
                local name=$(basename "$f" .log)
                while IFS='|' read -r ts val; do
                    [ $first -eq 1 ] && first=0 || echo "," >> "$out"
                    printf '  {"type":"%s","time":"%s","value":"%s"}' "$name" "$ts" "$val" >> "$out"
                done < "$f"
            done
            echo "\n]" >> "$out"
            ;;
        csv)
            echo "type,time,value" > "$out"
            for f in "$DATA_DIR"/*.log; do
                [ -f "$f" ] || continue
                local name=$(basename "$f" .log)
                while IFS='|' read -r ts val; do echo "$name,$ts,$val" >> "$out"; done < "$f"
            done
            ;;
        txt)
            echo "=== Heartrate Export ===" > "$out"
            for f in "$DATA_DIR"/*.log; do
                [ -f "$f" ] || continue
                echo "--- $(basename "$f" .log) ---" >> "$out"
                cat "$f" >> "$out"
            done
            ;;
        *) echo "Formats: json, csv, txt"; return 1 ;;
    esac
    echo "Exported to $out ($(
...[truncated 3130 chars]
Remediation
View remediation

Remediation Suggestions

  1. Set an owner-only umask before creating any data:

    bash
    umask 077
    
  2. Create and normalize the data directory with owner-only permissions:

    bash
    DATA_DIR="${HOME}/.local/share/heartrate"
    mkdir -p -m 700 "$DATA_DIR"
    chmod 700 "$DATA_DIR"
    
  3. Ensure every existing and newly generated log or export file is owner-readable and owner-writable only:

    bash
    chmod 600 "$DATA_DIR"/*.log "$DATA_DIR"/export.* 2>/dev/null || true
    
  4. Create export files securely rather than relying solely on ordinary redirection. Create a temporary owner-only file within the protected directory, write the complete report, and atomically rename it to the destination.

  5. Check the ownership of an existing data directory before using it. Refuse operation if it is not owned by the current user or if unsafe group/other write permissions are present.

  6. Consider optional encryption at rest for health records and exports where the threat model includes privileged local users, device theft, or filesystem backup exposure. File permissions alone do not protect against administrators or offline disk access.

Vulnerability Patterns
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (7)

Tp4

High
Category
MCP Tool Poisoning
Confidence
98% confidence
Finding

The description presents a focused heart-rate tracker for recording BPM readings, tracking trends, and charting weekly averages. The code does not implement heart-rate-specific logic, BPM validation, trend calculation, weekly averaging, or goal analysis. Instead, it accepts arbitrary text input and appends it to category-specific log files in a local data directory, then offers generic management functions like search, recent activity, status, summary counts, and export. While some command names loosely align with the declared purpose (log, track, chart, goal, weekly, trend), the actual behavior is materially broader and more generic than described, with several undeclared capabilities and without the core promised analytics.

Content

No source excerpt is available for this finding.

Description-Behavior Mismatch

High
Category
Not specified by scanner
Confidence
99% confidence
Finding

The help text advertises export <fmt> as a data export feature, but the first export) case in the dispatcher instead records arbitrary user input into export.log. In a health-data context, this can mislead users into entering sensitive data under the assumption it will be exported, causing unintended persistent storage of health information and undermining trust in data-handling behavior.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

High
Category
Not specified by scanner
Confidence
99% confidence
Finding

The documented behavior and actual command path are inconsistent: users are told export <fmt> performs export, but the matched branch logs the provided text instead. In a heart-rate tool, that mismatch increases the chance that users disclose sensitive health data or metadata expecting a benign export operation, resulting in unintended local retention.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The skill handles sensitive health-related information and states that it keeps automatic history and activity logs on disk, but it does not prominently warn users about local retention or the sensitivity of stored data. This can lead to inadvertent exposure through shared accounts, backups, endpoint compromise, or casual local access, especially because users may assume a lightweight wellness tool does not persist detailed health activity.

Content

No source excerpt is available for this finding.

Description-Behavior Mismatch

Medium
Category
Not specified by scanner
Confidence
96% confidence
Finding

The manifest describes a focused skill for recording heart rate readings, tracking BPM trends, and setting cardiovascular goals. However, the CLI exposes numerous generic commands such as remind, monthly, compare, streak, milestone, search, recent, and status, and each simply stores arbitrary input strings rather than heart-rate-specific BPM data or weekly-average calculations.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The script persistently stores heart-rate-related inputs and activity history under ~/.local/share/heartrate without any upfront warning, consent flow, or retention guidance. Because the skill handles health data, silent local logging raises confidentiality and privacy risks, especially on shared systems or environments with routine backups and broad home-directory access.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Low
Category
Not specified by scanner
Confidence
79% confidence
Finding

The documentation explicitly promises offline-only behavior and that user data never leaves the machine. In the same document, it directs users to external web and email endpoints for feedback, which contradicts the absolute wording of the offline claim even though it is not core runtime code behavior.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.