Back to skill

Security audit

pc-assistant

Security checks for vulnerabilities and agentic risk

Overview

This PC healthcheck skill is mostly a diagnostic tool, but it saves broad sensitive local data into plaintext reports with unsafe defaults and weak scoping.

Install only if you are comfortable with a tool that inventories sensitive local system details. Do not run it as root, do not share generated reports, avoid the default /tmp output paths, and prefer a private directory with restrictive permissions. The publisher should remove raw environment/history/SSH content collection, add redaction and explicit opt-in for security-audit sections, and replace sourced shell config with a safe parser before normal use.

Vulnerability Patterns
  • 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
  • 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
Findings (3)

T05 · Unauthorized Access and Privilege Escalation

Error
Location
scripts/healthcheck.sh:351
Finding
Excessive Collection of Sensitive User and System Data## Vulnerability Details **File Location**: `scripts/healthcheck.sh:351-365`, `scripts/healthcheck.sh:437-451`, and `scripts/healthcheck.sh:560-570` **Vulnerability Type**: Sensitive information collection beyond least-privilege requirements **Risk Level**: High ### Vulnerable Code ```bash subsection "6.4 SSH Keys & Access" { echo "=== SSH Authorized Keys ===" if [ -d ~/.ssh ]; then for keyfile in ~/.ssh/authorized_keys ~/.ssh/authorized_keys2; do [ -f "$keyfile" ] && echo "$keyfile:" && cat "$keyfile" | head -5 done fi echo "" echo "=== SSH Known Hosts ===" if [ -f ~/.ssh/known_hosts ]; then head -10 ~/.ssh/known_hosts fi } >> "$REPORT_FILE" ``` ```bash subsection "8.1 Environment Variables" { echo "=== Key Environment Variables ===" echo "PATH: $PATH" | head -5 echo "" echo "=== All Environment Variables ===" env | sort | head -40 } >> "$REPORT_FILE" subsection "8.2 Shell Configuration" { echo "=== Shell History (last 20) ===" if [ -f ~/.bash_history ]; then tail -20 ~/.bash_history fi echo "" echo "=== Aliases ===" alias 2>/dev/null | head -20 } >> "$REPORT_FILE" ``` ```bash subsection "12.1 User Crontab" crontab -l 2>/dev/null >> "$REPORT_FILE" || echo "No user crontabs" >> "$REPORT_FILE" subsection "12.2 System Cron" { echo "=== /etc/crontab ===" cat /etc/crontab 2>/dev/null echo "" echo "=== Cron.d files ===" ls -la /etc/cron.d/ 2>/dev/null } >> "$REPORT_FILE" ``` ### Technical Analysis The declared purpose is PC health diagnostics. CPU, memory, storage, service status, and aggregate security indicators are reasonably related to that purpose. Copying SSH authorization records, known-host entries, arbitrary environment-variable values, command ...[truncated 2193 chars]
Remediation
## Remediation Suggestions 1. Remove raw environment-variable and shell-history collection from the default health check. 2. Do not copy `authorized_keys` or `known_hosts` contents. Report only non-sensitive metadata such as: - Whether the files exist. - File ownership and permission modes. - Number of authorized entries. - Cryptographic fingerprints without comments or key material, when explicitly requested. 3. Replace complete cron output with aggregate information, such as the number of configured jobs and whether expected scheduler entries exist. 4. Put all security-sensitive inspection behind explicit, separate opt-in flags. 5. Redact values matching secret-bearing names such as `TOKEN`, `PASSWORD`, `SECRET`, `API_KEY`, and credential URL patterns. 6. Warn users before collecting data that may identify remote systems or authorization relationships. 7. Refuse privileged execution by default, or require an explicit option after clearly explaining the expanded collection scope.

T09 · Insecure Skill Coding Practices

Error
Location
scripts/healthcheck.sh:29
Finding
Sensitive Reports Are Created in Predictable Temporary Paths Without Restrictive Permissions## Vulnerability Details **File Location**: `scripts/healthcheck.sh:29-34` and `scripts/healthcheck.sh:60-72`; related scheduler defaults at `scripts/schedule.sh:21-30` **Vulnerability Type**: Insecure temporary-file handling and plaintext sensitive-data exposure **Risk Level**: High ### Vulnerable Code ```bash OUTPUT_DIR="${1:-/tmp/pc-healthcheck}" TIMESTAMP=$(date +%Y%m%d_%H%M%S) REPORT_FILE="${OUTPUT_DIR}/healthcheck_${TIMESTAMP}.txt" JSON_FILE="${OUTPUT_DIR}/healthcheck_${TIMESTAMP}.json" ``` ```bash # Create output directory mkdir -p "$OUTPUT_DIR" # Log mode if [ "$QUICK_MODE" = "1" ]; then log_info "Running in QUICK mode (fast, essential checks only)" fi log_info "Starting Enhanced PC Healthcheck..." log_info "Output directory: $OUTPUT_DIR" # Initialize report cat > "$REPORT_FILE" << 'EOF' ================================================================================ 🖥️ ENHANCED PC HEALTHCHECK REPORT ================================================================================ EOF ``` The scheduler uses the same insecure pattern: ```bash OUTPUT_DIR="${PC_ASSISTANT_OUTPUT_DIR:-/tmp/pc-healthcheck-reports}" setup_output() { mkdir -p "$OUTPUT_DIR" } ``` ### Technical Analysis The reports contain hostnames, usernames, processes, network connections, listening ports, package inventories, logs, SSH access records, environment values, shell history, and cron configuration. Despite this sensitivity, the scripts do not establish a restrictive `umask`, enforce directory mode `0700`, enforce report mode `0600`, verify ownership, reject symbolic links, or create files atomically. Under a common `022` umask, `mkdir -p` creates a directory with mode `0755`, while shell redirection creates report files with mode `0644`. This can make reports readable by other local users. The global `/tmp/pc-healthcheck` and `/tmp/pc-healthcheck-reports` name ...[truncated 2174 chars]
Remediation
## Remediation Suggestions 1. Set a restrictive mask before creating any output: ```bash umask 077 ``` 2. Default to a private per-user state directory rather than a shared global temporary name: ```bash OUTPUT_DIR="${XDG_STATE_HOME:-$HOME/.local/state}/pc-assistant" ``` 3. Create and validate the directory with mode `0700`, and verify that it is owned by the current effective user. 4. Reject symbolic links and unsafe pre-existing directories. 5. Use `mktemp` inside the validated private directory to create report files atomically. 6. Explicitly set report permissions to `0600`. 7. Avoid second-resolution predictable names as the security boundary; add cryptographically unpredictable filename components. 8. If a custom output directory is supplied, reject directories that are world-writable, not owned by the caller, or reached through symbolic links. 9. Keep scheduled reports in a private directory and document the enforced permission model rather than relying on user guidance alone.

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/schedule.sh:10
Finding
Scheduler Executes Configuration Files as Arbitrary Shell Code## Vulnerability Details **File Location**: `scripts/schedule.sh:10-25` and `scripts/schedule.sh:139-151` **Vulnerability Type**: Arbitrary command execution through unsafe configuration loading **Risk Level**: Medium ### Vulnerable Code ```bash # Default config location CONFIG_FILE="${PC_ASSISTANT_CONFIG:-$HOME/.config/pc-assistant.conf}" # Load config if exists load_config() { if [[ -f "$CONFIG_FILE" ]]; then # shellcheck disable=SC1090 source "$CONFIG_FILE" fi # Defaults OUTPUT_DIR="${PC_ASSISTANT_OUTPUT_DIR:-/tmp/pc-healthcheck-reports}" REPORT_PREFIX="${PC_ASSISTANT_REPORT_PREFIX:-HealthCheck}" NOTIFY="${PC_ASSISTANT_NOTIFY:-false}" KEEP_DAYS="${PC_ASSISTANT_KEEP_DAYS:-30}" CLEANUP="${PC_ASSISTANT_CLEANUP:-false}" } ``` ```bash while [[ $# -gt 0 ]]; do case $1 in -c|--config) CONFIG_FILE="$2" shift 2 ;; -o|--output) OUTPUT_DIR="$2" shift 2 ;; -p|--prefix) REPORT_PREFIX="$2" shift 2 ;; ``` ### Technical Analysis Documentation presents `pc-assistant.conf` as a data file containing configuration assignments. The implementation loads it with the Bash `source` builtin. `source` does not parse configuration data safely; it executes the entire file as shell code in the scheduler process. The path can be selected through `PC_ASSISTANT_CONFIG` or `--config`, and the implementation only checks whether the path is a regular file. It does not verify ownership, permission mode, symbolic-link status, or whether the file resides in a trusted directory. Consequently, shell substitutions, function calls, redirections, and arbitrary commands placed in the configuration file execute with the scheduler user's privileges. The risk is amplified when the scheduler is invoked unattended through cron. ### Att ...[truncated 1371 chars]
Remediation
## Remediation Suggestions 1. Do not use `source`, `.`, or `eval` to load configuration. 2. Parse only an explicit allowlist of supported keys: - `PC_ASSISTANT_OUTPUT_DIR` - `PC_ASSISTANT_REPORT_PREFIX` - `PC_ASSISTANT_KEEP_DAYS` - `PC_ASSISTANT_CLEANUP` - `PC_ASSISTANT_NOTIFY` 3. Use a non-executable format such as JSON or a strict line-oriented parser. 4. Reject command substitutions, shell metacharacters, duplicate keys, unknown keys, and malformed values. 5. Validate types and ranges, particularly requiring `KEEP_DAYS` to be a bounded non-negative integer. 6. Require the configuration file to be owned by the effective user, not group- or world-writable, and not a symbolic link. 7. Require trusted ownership and safe permissions on parent directories. 8. For unattended execution, use a minimal fixed environment and an absolute trusted configuration path. 9. Document that configuration is treated strictly as data and add regression tests proving that shell syntax is never executed.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Rogue AgentSelf-Modification, Session Persistence
Findings (29)

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding
The documented behavior describes a generic read-only healthcheck, but the skill also advertises collection of sensitive security, user, package, network, and system configuration data and persistent report generation. That mismatch matters because users may consent to a benign-seeming diagnostic while the skill performs broader host reconnaissance and stores the results on disk, increasing exposure of sensitive local information.

Description-Behavior Mismatch

High
Confidence
99% confidence
Finding
This section collects SSH authorized_keys, known_hosts, account data, login history, and failed-login records, which goes well beyond ordinary PC health diagnostics. In the context of a 'healthcheck' skill, this is dangerous because it silently expands into security/audit and credential-adjacent collection without clear need or consent.

Context-Inappropriate Capability

High
Confidence
99% confidence
Finding
Reading ~/.ssh/authorized_keys and ~/.ssh/known_hosts is not necessary for system health assessment and exposes sensitive trust relationships and access configuration. Even partial contents can aid attacker profiling, lateral movement planning, and identification of privileged infrastructure.

Missing User Warnings

High
Confidence
99% confidence
Finding
The script writes contents of authorized_keys files directly into a plaintext report without explicit warning or consent. Although public keys are not private keys, they still disclose trusted identities, access scope, and potentially sensitive comments or usernames that can aid targeting.

Ssd 3

High
Confidence
100% confidence
Finding
The script aggregates multiple classes of sensitive local data—SSH configuration, login records, environment variables, shell history, network details, package inventories, and system state—into plaintext report files. The combination materially increases risk because it creates a centralized, durable dossier useful for credential theft, reconnaissance, and post-compromise escalation.

Credential Access

High
Category
Privilege Escalation
Content
{
    echo "=== SSH Authorized Keys ==="
    if [ -d ~/.ssh ]; then
        for keyfile in ~/.ssh/authorized_keys ~/.ssh/authorized_keys2; do
            [ -f "$keyfile" ] && echo "$keyfile:" && cat "$keyfile" | head -5
        done
    fi
Confidence
99% confidence
Finding
Accessing ~/.ssh/authorized_keys is credential-adjacent data collection that exposes trusted access relationships and can reveal user identities or administrative patterns. In a healthcheck skill, this is unnecessary and increases the chance of sensitive disclosure if reports are read by others.

Credential Access

High
Category
Privilege Escalation
Content
fi
    echo ""
    echo "=== SSH Known Hosts ==="
    if [ -f ~/.ssh/known_hosts ]; then
        head -10 ~/.ssh/known_hosts
    fi
} >> "$REPORT_FILE"
Confidence
97% confidence
Finding
Accessing ~/.ssh/known_hosts can disclose internal network structure and prior trust relationships with remote systems. This is credential-adjacent reconnaissance data and is not required for PC health diagnostics.

Credential Access

High
Category
Privilege Escalation
Content
echo ""
    echo "=== SSH Known Hosts ==="
    if [ -f ~/.ssh/known_hosts ]; then
        head -10 ~/.ssh/known_hosts
    fi
} >> "$REPORT_FILE"
Confidence
97% confidence
Finding
This line outputs known_hosts content into the report, turning sensitive trust metadata into a persistent artifact. The context makes it more dangerous because the skill advertises routine diagnostics, so users may not expect host-trust data to be collected and stored.

Context-Inappropriate Capability

High
Confidence
100% confidence
Finding
Dumping environment variables and shell history is highly sensitive and unjustified for a read-only PC diagnostics tool. Environment variables frequently contain tokens, passwords, API keys, and internal endpoints, while shell history may reveal credentials, commands, and operational context.

Missing User Warnings

High
Confidence
100% confidence
Finding
Writing environment variables to the report can expose secrets such as API tokens, cloud credentials, proxy credentials, and internal service URLs. Because the report is saved to disk, this turns transient process state into a durable secret leak.

Missing User Warnings

High
Confidence
99% confidence
Finding
Shell history often contains credentials, hostnames, operational commands, and sensitive file paths. Copying the last 20 commands into a plaintext report without warning creates a direct disclosure channel unrelated to normal health diagnostics.

Context-Inappropriate Capability

High
Confidence
99% confidence
Finding
The script uses 'source "$CONFIG_FILE"' on a user-controlled path, which executes arbitrary shell code in the script's context rather than merely parsing configuration values. If this scheduler is run manually, via cron, or with elevated privileges, an attacker who can modify the config file or influence PC_ASSISTANT_CONFIG can achieve arbitrary command execution.

Description-Behavior Mismatch

High
Confidence
97% confidence
Finding
The manifest explicitly says the skill is for "Read-only system diagnostics," but this script creates output directories, writes recommendation files, renames reports, deletes generated JSON, and optionally deletes older reports. Those are substantive filesystem modifications, not merely passive diagnostics behavior.

Description-Behavior Mismatch

Medium
Confidence
97% confidence
Finding
The skill is described as read-only, but the documentation explicitly says it writes timestamped reports to disk and supports scheduled report generation. Misrepresenting side effects undermines informed consent and can lead to sensitive diagnostic data being persisted in locations the user did not expect.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The documentation lacks a clear warning that generated reports may contain sensitive local system details such as user, network, software, security, and hardware information. Without that warning, users may share or store reports insecurely, creating unnecessary exposure of reconnaissance-grade host data.

Vague Triggers

Medium
Confidence
95% confidence
Finding
The 'When to Use' section includes generic phrases like 'system check', 'diagnostics', 'how is my PC doing?', and 'is everything ok?'. These are broad, conversational requests without clear scope boundaries or exclusions, which could cause the skill to activate for unrelated troubleshooting contexts.

Session Persistence

Medium
Category
Rogue Agent
Content
### Configuration Options

Create a config file at `~/.config/pc-assistant.conf`:

```bash
# Output directory for reports
Confidence
74% confidence
Finding
The documented use of a persistent config file in the user's home directory introduces session persistence for behavior such as output location, retention, and cleanup. Persistence is not inherently malicious here, but it can silently alter future executions and increase the chance of long-term storage or deletion of sensitive reports without fresh user awareness.

Intent-Code Divergence

Medium
Confidence
95% confidence
Finding
Claiming the script is read-only and safe to run repeatedly conflicts with the documented cleanup behavior that can delete old report files. Even if deletion is limited to generated artifacts, this is still a write/delete side effect that should be disclosed because users may enable automation and unintentionally lose stored reports.

Ae2

Medium
Category
analysis-evasion
Confidence
90% confidence
Finding
Artifact content does not match its filename extension

Unsafe Defaults

Medium
Category
Tool Misuse
Content
# Security notes:
# - Reports contain system info, SSH key filenames, package lists
# - Do not share reports publicly or leave in world-readable locations
# - When scheduling, use a private output directory
# - Run as regular user, not root
Confidence
70% confidence
Finding
Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.

Description-Behavior Mismatch

Medium
Confidence
98% confidence
Finding
The skill metadata claims read-only diagnostics, but the script creates an output directory and writes both text and JSON reports to disk. This breaks the stated trust boundary and can leave sensitive diagnostic artifacts behind in a predictable location such as /tmp, increasing exposure to other local users or later exfiltration.

Context-Inappropriate Capability

Medium
Confidence
95% confidence
Finding
Collecting login history, failed-login events, and cron contents expands the tool into user activity and persistence auditing rather than basic health diagnostics. In this skill context, that broader collection increases privacy and security risk without being clearly justified by the description.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
Known_hosts entries reveal systems the user has connected to and can expose internal hostnames, IPs, and infrastructure relationships. Storing even the first lines in an unprotected diagnostic report creates unnecessary reconnaissance value for an attacker.

Session Persistence

Medium
Category
Rogue Agent
Content
section "12. CRON & SCHEDULED TASKS"

subsection "12.1 User Crontab"
crontab -l 2>/dev/null >> "$REPORT_FILE" || echo "No user crontabs" >> "$REPORT_FILE"

subsection "12.2 System Cron"
{
Confidence
85% confidence
Finding
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Session Persistence

Medium
Category
Rogue Agent
Content
subsection "12.2 System Cron"
{
    echo "=== /etc/crontab ==="
    cat /etc/crontab 2>/dev/null
    echo ""
    echo "=== Cron.d files ==="
    ls -la /etc/cron.d/ 2>/dev/null
Confidence
85% confidence
Finding
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Static analysis

No suspicious patterns detected.