Linux Patcher

• Outcome: Review
• Latest audit: Sep 10, 2026 · 10:20 AM UTC
• Version: 3.0.2

Overview

The skill is a real server-patching tool, but it asks for broad production access and contains unsafe update, credential, and remote-command handling that should be reviewed before installation.

Install only after reviewing the scripts and tightening controls: remove curl -k, avoid sourcing generated or user-supplied config files, validate hostnames/users/paths, avoid curl | sudo bash for PatchMon, keep Docker updates opt-in, and grant sudo through narrow audited wrappers rather than broad passwordless Docker commands.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (6)

T03 · Remote Payload Retrieval and Execution

Error

• Location: references/patchmon-setup.md:114
• Finding: Unpinned Remote Installation Script Executed as Root and Installed Persistently<![CDATA[ ## Vulnerability Details **File Location**: `references/patchmon-setup.md:114-137` **Vulnerability Type**: Unverified remote code execution and persistent service installation **Risk Level**: Critical ### Vulnerable Code ```bash curl -sSL https://raw.githubusercontent.com/PatchMon/PatchMon/main/agent/install.sh | sudo bash ``` The installed agent is configured to update itself: ```yaml features: auto_update: true # Auto-update agent itself docker: true # Enable Docker monitoring ``` It is then registered to start automatically: ```bash sudo systemctl enable patchmon-agent sudo systemctl start patchmon-agent ``` ### Technical Analysis The installation instructions stream a shell script from the mutable `main` branch of an external GitHub repository directly into a root shell. The downloaded content is not pinned to an immutable release or commit, inspected before execution, or verified with a cryptographic signature or checksum. Consequently, the code that executes can change after this Skill has been reviewed. Compromise of the upstream repository, maintainer account, GitHub delivery infrastructure, or installation URL would provide an attacker with arbitrary root-level code execution on every host where the documented command is used. The risk continues after installation because the resulting agent is enabled as a system service and configured with `auto_update: true`. These behaviors are related to PatchMon monitoring, but they exceed the minimum privileges required for the core host-patching scripts and create a persistent third-party execution channel. ### Attack Path 1. An attacker compromises the upstream PatchMon repository, maintainer credentials, release process, or delivery channel. 2. The attacker modifies `agent/install.sh` on the referenced `main` branch. 3. An administrator follows the Skill documentation and runs the `curl | sudo bash` command. 4. The malicious script executes immediately with root privileges. 5. ...[truncated 722 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not pipe remotely downloaded content directly into a shell, especially a privileged shell. 2. Pin the installation artifact to an immutable release version or audited commit hash. 3. Download the artifact to a local file before execution: ```bash curl --fail --show-error --location \ --output patchmon-install.sh \ https://example.invalid/pinned-release/install.sh ``` 4. Verify a vendor-provided cryptographic signature and an independently published SHA-256 digest. 5. Review the downloaded script before running it with elevated privileges. 6. Run installation through a narrowly scoped, documented privileged procedure. 7. Default `auto_update` to `false`; require explicit approval for upgrades. 8. Require explicit confirmation before enabling a persistent system service. 9. Document the files, user account, network access, and privileges created by the agent. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/patchmon-query.sh:46
• Finding: TLS Certificate Verification Disabled for Credentials and Bearer Tokens<![CDATA[ ## Vulnerability Details **File Location**: `scripts/patchmon-query.sh:46-63` **Vulnerability Type**: Sensitive-data transmission over an unauthenticated TLS connection **Risk Level**: High ### Vulnerable Code ```bash TOKEN=$(curl -s -k -X POST "$PATCHMON_URL/api/auth/login" \ -H "Content-Type: application/json" \ -d "{\"username\":\"$PATCHMON_USERNAME\",\"password\":\"$PATCHMON_PASSWORD\"}" \ | jq -r '.token // .accessToken // empty') if [ -z "$TOKEN" ] || [ "$TOKEN" = "null" ]; then echo "ERROR: Failed to authenticate with PatchMon" echo "Check credentials in: $PATCHMON_CONFIG" exit 1 fi echo "✓ Authenticated successfully" echo "" # Query hosts needing updates echo "Querying hosts from PatchMon..." HOSTS_JSON=$(curl -s -k "$PATCHMON_URL/api/v1/dashboard/hosts" \ -H "Authorization: Bearer $TOKEN") ``` ### Technical Analysis The `-k` option instructs `curl` to accept invalid or untrusted TLS certificates. This disables server identity verification while transmitting the PatchMon username and password and while using the resulting bearer token. Encryption without certificate validation does not protect against an active man-in-the-middle attacker. A malicious endpoint can impersonate the PatchMon server, collect credentials, issue a forged token, and return attacker-controlled inventory data. The script also does not enforce an HTTPS URL scheme. A user-controlled `PATCHMON_URL` could therefore use plaintext HTTP or an unexpected protocol supported by `curl`. ### Attack Path 1. An attacker gains a position on the network path, controls DNS resolution, or redirects traffic through a malicious proxy. 2. The attacker presents an arbitrary TLS certificate for the PatchMon hostname. 3. Because `curl -k` accepts the certificate, the script sends the PatchMon username and password to the attacker. 4. The attacker returns a forged authentication response containing a token. 5. The subsequent inventory request is also interc ...[truncated 639 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove `-k` from every `curl` invocation. 2. Reject `PATCHMON_URL` values that do not use `https://`. 3. For private certificate authorities, accept a configured CA bundle through `--cacert` rather than disabling verification. 4. Use `--fail-with-body`, `--show-error`, and explicit connection and request timeouts. 5. Restrict or disable redirects; if redirects are required, verify that they remain on the approved origin. 6. Prefer a narrowly scoped, revocable API token over a reusable account password. 7. Validate the expected response schema before consuming any returned data. 8. Update troubleshooting documentation that currently recommends `curl -k`. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/patchmon-query.sh:87
• Finding: PatchMon API Data Is Converted into Executable Shell Configuration<![CDATA[ ## Vulnerability Details **File Location**: `scripts/patchmon-query.sh:87-100`; execution occurs at `scripts/patch-auto.sh:40-58` **Vulnerability Type**: Local shell command injection through untrusted API fields **Risk Level**: Critical ### Vulnerable Code The PatchMon fields are embedded into Bash source code without shell-safe encoding: ```bash cat > "$OUTPUT_CONFIG" << 'EOF' #!/bin/bash # Auto-generated PatchMon host configuration # Generated: $(date) # Host definitions parsed from PatchMon HOSTS=( EOF # Parse each host and add to config echo "$NEEDS_UPDATE" | jq -r '"\(.hostname),\(.sshUser // ""),\(.dockerPath // "")"' | while read -r line; do echo " \"$line\"" >> "$OUTPUT_CONFIG" done cat >> "$OUTPUT_CONFIG" << 'EOF' ) ``` The generated file is subsequently executed through `source`: ```bash TEMP_CONFIG=$(mktemp) if ! "$SCRIPT_DIR/patchmon-query.sh" --output-config "$TEMP_CONFIG"; then echo "ERROR: Failed to query PatchMon" rm -f "$TEMP_CONFIG" exit 1 fi # ... source "$TEMP_CONFIG" ``` ### Technical Analysis The values of `.hostname`, `.sshUser`, and `.dockerPath` originate from the PatchMon API. They are inserted between double quotes in an executable Bash array without escaping embedded quotes, command substitutions, newlines, backticks, or other shell syntax. The resulting file is then loaded using `source`, which executes all shell syntax in that file. A malicious field can close the intended string and insert arbitrary commands. Using `mktemp` prevents a simple predictable-file race, but it does not make attacker-controlled file contents safe to execute. Disabled TLS verification makes it possible for a network attacker to forge the API response even without compromising PatchMon itself. ### Attack Path 1. An attacker compromises PatchMon, modifies a host record, or intercepts the API connection. 2. The attacker supplies a crafted `hostname`, `sshUser`, or `dockerPath` containing quotes and shell syntax. 3 ...[truncated 942 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Never serialize API data into executable shell code. 2. Keep the response as JSON and iterate over records directly with `jq`, `mapfile`, or a non-shell parser. 3. Use an unambiguous transport such as NUL-delimited fields if Bash must process records. 4. Validate every field: - Hostnames must match an approved hostname or IP-address grammar. - SSH usernames must match a strict account-name grammar. - Docker paths must be canonical absolute paths without control characters. 5. Do not use `source` to parse generated inventory. 6. If shell serialization is unavoidable, encode every value with `printf '%q'`; this is defense in depth, not a substitute for avoiding executable formats. 7. Authenticate the PatchMon connection and validate the JSON response schema before processing it. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/patch-host-full.sh:94
• Finding: Untrusted Docker Path Is Interpolated into Remote Shell Commands<![CDATA[ ## Vulnerability Details **File Location**: `scripts/patch-host-full.sh:94-116`; upstream API input is passed at `scripts/patch-auto.sh:79-135` **Vulnerability Type**: Remote shell command injection **Risk Level**: High ### Vulnerable Code ```bash echo "" echo "Step 1/5: Updating system packages..." ssh "$HOST" "sudo $UPDATE_CMD && sudo $UPGRADE_CMD && sudo $AUTOREMOVE_CMD" || { echo "ERROR: Failed to update packages on $HOST" exit 1 } echo "Step 2/5: Cleaning Docker cache..." ssh "$HOST" "sudo docker system prune -af" || { echo "WARNING: Docker cleanup failed (continuing anyway)" } echo "Step 3/5: Pulling updated Docker images..." ssh "$HOST" "cd $DOCKER_PATH && sudo docker images --format '{{.Repository}}:{{.Tag}}' | grep -v '<none>' | xargs -r -L1 sudo docker pull" || { echo "WARNING: Some image pulls failed (continuing anyway)" } echo "Step 4/5: Pulling compose images..." ssh "$HOST" "cd $DOCKER_PATH && sudo docker compose pull" || { echo "ERROR: Docker compose pull failed on $HOST" exit 1 } echo "Step 5/5: Recreating containers..." ssh "$HOST" "cd $DOCKER_PATH && sudo docker compose up -d" || { echo "ERROR: Docker compose up failed on $HOST" exit 1 } ``` The value may originate from PatchMon: ```bash IFS=',' read -r hostname ssh_user docker_path <<< "$host_entry" # ... if DRY_RUN="$DRY_RUN" "$SCRIPT_DIR/patch-host-full.sh" "$SSH_TARGET" "$docker_path"; then ``` ### Technical Analysis `DOCKER_PATH` is concatenated into a double-quoted SSH command and interpreted by the remote shell. The variable is not restricted to a canonical absolute path and is not quoted for the remote-shell parsing layer. Shell metacharacters, command substitutions, or separators in the path can therefore change the command executed on the target. The input can be supplied manually or obtained from PatchMon host metadata. Local quoting of `"$DOCKER_PATH"` when passing it to `patch-host-full.sh` does not protect the value after it ...[truncated 1025 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Require `DOCKER_PATH` to be a canonical absolute path. 2. Reject newlines, control characters, shell metacharacters, relative components, and paths outside approved project roots. 3. Do not concatenate input into a remote command string. 4. Pass the path as an argument to a fixed remote script and quote it using a shell-safe positional-argument mechanism. 5. Prefer deploying an audited helper on the remote host that accepts a project identifier rather than an arbitrary path. 6. Ensure the selected Compose file and directory are root-owned and not writable by the SSH account. 7. Treat all PatchMon inventory fields as untrusted, even when TLS validation is corrected. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/patchmon-query.sh:7
• Finding: Credential and Inventory Configuration Files Are Executed with Source<![CDATA[ ## Vulnerability Details **File Location**: `scripts/patchmon-query.sh:7-20`; related batch loader at `scripts/patch-multiple.sh:13-23` **Vulnerability Type**: Arbitrary local code execution through executable configuration files **Risk Level**: High ### Vulnerable Code Credential configuration: ```bash # Load PatchMon credentials PATCHMON_CONFIG="${PATCHMON_CONFIG:-$HOME/.patchmon-credentials.conf}" if [ ! -f "$PATCHMON_CONFIG" ]; then echo "ERROR: PatchMon credentials not found: $PATCHMON_CONFIG" echo "" echo "Create the file with:" echo " PATCHMON_URL=https://patchmon.example.com" echo " PATCHMON_USERNAME=admin" echo " PATCHMON_PASSWORD=your-password" exit 1 fi source "$PATCHMON_CONFIG" ``` Batch inventory configuration: ```bash CONFIG_FILE="$1" if [ ! -f "$CONFIG_FILE" ]; then echo "ERROR: Config file not found: $CONFIG_FILE" exit 1 fi # Load configuration source "$CONFIG_FILE" ``` ### Technical Analysis Bash `source` does not parse a passive key/value configuration format. It executes the target file as shell code in the current process. Any command substitution, function, redirection, command, or shell option in the credential or inventory file executes before the script validates the expected variables. The credential-file location is also controlled by the `PATCHMON_CONFIG` environment variable, while the batch configuration path is supplied on the command line. File existence checks do not establish ownership, permissions, integrity, or whether the file contents are safe. ### Attack Path 1. An attacker modifies a credential or inventory file, places a malicious file at an operator-selected path, or influences `PATCHMON_CONFIG`. 2. The operator starts `patchmon-query.sh` or `patch-multiple.sh`. 3. The script confirms only that the path exists as a file. 4. `source` evaluates the file in the current shell. 5. Attacker commands execute with the operator's privileges before configuration valida ...[truncated 581 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace shell configuration with JSON, TOML, YAML, or another non-executable format. 2. Parse only the explicitly supported keys and reject unknown values. 3. For the credential file, enforce: - A regular file rather than a symlink. - Ownership by the current user. - No group or world permissions. 4. Avoid allowing unrestricted environment-controlled configuration paths in privileged or automated contexts. 5. For host inventory, validate every hostname, username, path, update mode, and Boolean value. 6. Document the expected file schema and fail closed on malformed input. 7. Keep credentials separate from executable scripts and inventory data. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SETUP.md:108
• Finding: Passwordless Root Docker Permissions Break the Claimed Least-Privilege Boundary<![CDATA[ ## Vulnerability Details **File Location**: `SETUP.md:108-115`; equivalent rules appear at `SETUP.md:140-146` and `SETUP.md:165-171` **Vulnerability Type**: Excessive passwordless sudo privileges **Risk Level**: High ### Vulnerable Code ```sudoers # Docker management only (if using Docker updates) admin ALL=(ALL) NOPASSWD: /usr/bin/docker system prune admin ALL=(ALL) NOPASSWD: /usr/bin/docker pull * admin ALL=(ALL) NOPASSWD: /usr/bin/docker compose pull admin ALL=(ALL) NOPASSWD: /usr/bin/docker compose up admin ALL=(ALL) NOPASSWD: /usr/bin/docker images ``` Equivalent passwordless Docker permissions are recommended for the RHEL-family and SUSE configurations. ### Technical Analysis The documentation describes these rules as minimal permissions. However, Docker management is a highly privileged capability. In particular, running `docker compose up` as root can create containers based on a Compose file selected from the current directory. If the SSH account can create or modify that Compose file, it can define host filesystem mounts, privileged containers, host namespaces, devices, or other security-sensitive settings. Starting that project through root Docker can consequently provide control over the host. The permissions therefore exceed a narrow package-patching role. They also enlarge the impact of compromise of the automation account, SSH key, PatchMon inventory, or remote command construction. There is also a functional mismatch: the script invokes `docker system prune -af` and `docker compose up -d`, while sudoers entries with explicit arguments may not authorize additional arguments unless the policy is written to permit them. Administrators may respond by broadening the rules further, increasing exposure. ### Attack Path 1. An attacker compromises the patching SSH account or gains write access to an approved Compose project. 2. The attacker creates or alters a Compose definition to mount sensitive host paths or start a privileged conta ...[truncated 693 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Separate package-patching and container-deployment identities and permissions. 2. Do not grant generic passwordless Docker or Compose commands to an unprivileged automation account. 3. Implement a root-owned wrapper with: - A fixed, root-owned Compose project directory. - An approved Compose filename. - An allowlist of permitted images and registries. - Fixed arguments and environment variables. - Rejection of privileged mode, host namespaces, devices, and unsafe host mounts. 4. Ensure the SSH account cannot modify the wrapper, Compose file, project directory, or deployment environment. 5. Authorize only the wrapper in sudoers, with exact arguments. 6. Prefer a dedicated deployment service or orchestrator with scoped authorization and audit logging. 7. Make Docker updating opt-in rather than the default for generic “update my servers” requests. ]]>

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (119)

Credential Access

High

• Category: Privilege Escalation

Content

**Solutions:**
```bash
# 1. Verify key is added to target host
ssh admin@target "cat ~/.ssh/authorized_keys"

# 2. Check SSH key permissions
ls -la ~/.ssh/id_openclaw

• Confidence: 90% confidence
• Finding: The troubleshooting instruction to `cat ~/.ssh/authorized_keys` exposes the complete list of trusted public keys for the account in terminal output. While public keys are not secret like private keys, disclosing account access configuration can aid reconnaissance and may leak comments, usernames, hostnames, or key management details in shared support sessions.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

**Solutions:**
```bash
# 1. Test PatchMon connectivity
curl -k https://patchmon.example.com/api/health

# 2. Verify credentials
cat ~/.patchmon-credentials.conf

• Confidence: 93% confidence
• Finding: The troubleshooting block combines `curl -k` with manual authentication testing, weakening transport security for a privileged management system. Disabling certificate validation can let an attacker intercept or tamper with requests and capture PatchMon credentials, especially in enterprise environments using proxies or untrusted networks.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 92% confidence
• Finding: The code substantially aligns with the core declared purpose of patching Linux packages and updating Docker containers on a remote server. However, parts of the description overstate what this code chunk actually does. Most notably, there is no PatchMon integration and no automatic host detection; instead, the caller must provide user@hostname manually. The script also handles only one host at a time, so the description's implication of multi-host maintenance orchestration is not represented in this chunk. Additionally, while the script includes OS detection and package-manager abstraction for several distributions, it explicitly warns that only Ubuntu has been tested, making the strong support claim somewhat overstated. Because these are material descriptive mismatches rather than mere implementation details, this should be flagged as a mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The code’s core behavior is host-only Linux package patching via SSH, which partially matches the declared server patching purpose. However, the declared description explicitly includes Docker container updates and PatchMon-based automatic host detection, neither of which appear in this code chunk. The script also only operates on a single provided host argument rather than managing multiple hosts, and it notes that only Ubuntu has been fully tested despite the broad support claim. Because important declared capabilities are absent from the supplied code, the description does not accurately represent this chunk.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

**Install missing tools:**
```bash
# Ubuntu/Debian
sudo apt install curl jq

# RHEL/CentOS/Rocky/Alma
sudo dnf install curl jq

• Confidence: 60% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Credential Access

High

• Category: Privilege Escalation

Content

- Use `/etc/sudoers.d/` files (easier to manage)
- **SSH keys** should be protected
  - Use passphrase-protected keys when possible
  - Restrict key permissions: `chmod 600 ~/.ssh/id_rsa`
- **Review updates** before applying in production
  - Use dry-run mode first
  - Test on staging environment

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Vague Triggers

High

• Confidence: 99% confidence
• Finding: This section explicitly states that broad chat requests default to Docker-changing behavior, including pulling images and recreating containers. Defaulting to the more destructive path without a narrow trigger or approval materially raises the risk of unintended outages, supply-chain exposure from image pulls, and unauthorized maintenance actions.

Missing User Warnings

High

• Confidence: 95% confidence
• Finding: The workflow includes potentially disruptive and destructive actions such as package upgrades, 'docker system prune -af', image pulls, and 'docker compose up -d' without an explicit warning about service interruption, image/volume implications, rollback considerations, or approval gates. In a server-maintenance skill, omission of these warnings meaningfully raises the risk of production outages and unintended data or state loss.

Chaining Abuse

High

• Category: Tool Misuse

Content

Install PatchMon agent on each monitored host:

```bash
curl -sSL https://raw.githubusercontent.com/PatchMon/PatchMon/main/agent/install.sh | sudo bash
```

Configure agent (`/etc/patchmon/config.yml`):

• Confidence: 99% confidence
• Finding: The shell pipeline chains network retrieval directly into privileged execution, which is a classic abuse pattern because it converts any compromise of the fetched content into immediate root command execution. Given this skill patches Linux servers across multiple hosts, the context increases danger substantially by enabling rapid fleet-wide compromise.

Context-Inappropriate Capability

High

• Confidence: 99% confidence
• Finding: This is a true vulnerability because the script sources a temporary config file generated from PatchMon output, which causes any shell code in that file to execute locally with the privileges of the patching process. In this skill’s context, PatchMon is only supposed to supply host metadata, but `source "$TEMP_CONFIG"` turns a data channel into a code-execution channel, making compromise of PatchMon, its transport, or its output format highly dangerous.

Chaining Abuse

High

• Category: Tool Misuse

Content

echo ""
echo "Step 1/5: Updating system packages..."
ssh "$HOST" "sudo $UPDATE_CMD && sudo $UPGRADE_CMD && sudo $AUTOREMOVE_CMD" || {
    echo "ERROR: Failed to update packages on $HOST"
    exit 1
}

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

echo ""
echo "Step 1/5: Updating system packages..."
ssh "$HOST" "sudo $UPDATE_CMD && sudo $UPGRADE_CMD && sudo $AUTOREMOVE_CMD" || {
    echo "ERROR: Failed to update packages on $HOST"
    exit 1
}

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

echo ""
echo "Step 1/5: Updating system packages..."
ssh "$HOST" "sudo $UPDATE_CMD && sudo $UPGRADE_CMD && sudo $AUTOREMOVE_CMD" || {
    echo "ERROR: Failed to update packages on $HOST"
    exit 1
}

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

echo ""
echo "Step 1/5: Updating system packages..."
ssh "$HOST" "sudo $UPDATE_CMD && sudo $UPGRADE_CMD && sudo $AUTOREMOVE_CMD" || {
    echo "ERROR: Failed to update packages on $HOST"
    exit 1
}

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

}

echo "Step 3/5: Pulling updated Docker images..."
ssh "$HOST" "cd $DOCKER_PATH && sudo docker images --format '{{.Repository}}:{{.Tag}}' | grep -v '<none>' | xargs -r -L1 sudo docker pull" || {
    echo "WARNING: Some image pulls failed (continuing anyway)"
}

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Context-Inappropriate Capability

High

• Confidence: 99% confidence
• Finding: The script directly executes the user-supplied configuration file with `source`, which allows arbitrary shell commands in that file to run with the privileges of the patching process. In the context of a multi-host patching tool, operators may reasonably treat config files as data, so this creates a dangerous code-execution boundary that can lead to local compromise, credential theft, tampering with update targets, or malicious commands being run before patching begins.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

# Authenticate with PatchMon
echo "Authenticating with PatchMon..."
TOKEN=$(curl -s -k -X POST "$PATCHMON_URL/api/auth/login" \
    -H "Content-Type: application/json" \
    -d "{\"username\":\"$PATCHMON_USERNAME\",\"password\":\"$PATCHMON_PASSWORD\"}" \
    | jq -r '.token // .accessToken // empty')

• Confidence: 98% confidence
• Finding: Using curl -k disables certificate verification for the login request that carries PatchMon credentials. In a server-patching skill, this is especially dangerous because it undermines trust in the update-management backend and enables credential theft or session hijacking through man-in-the-middle attacks.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

# Query hosts needing updates
echo "Querying hosts from PatchMon..."
HOSTS_JSON=$(curl -s -k "$PATCHMON_URL/api/v1/dashboard/hosts" \
    -H "Authorization: Bearer $TOKEN")

# Parse hosts needing updates

• Confidence: 97% confidence
• Finding: The host-query request also uses curl -k, so the script accepts unauthenticated TLS endpoints when retrieving the list of hosts needing updates. An attacker who can intercept traffic could tamper with the returned host inventory, causing the surrounding patching workflow to target attacker-chosen systems or generate a malicious configuration file from falsified data.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The contribution instructions tell users to run scripts against a remote host and a host-only patching script without clearly warning that these commands may connect to real systems and alter their state. In a server patching skill, that omission is risky because contributors may test against production or otherwise sensitive hosts and trigger unintended maintenance actions.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The development setup section includes commands that probe or act on remote hosts but does not warn contributors that these scripts may affect the target machine. Because this skill is specifically designed for Linux patching and Docker updates, the lack of a safety notice increases the chance of accidental changes to live infrastructure during setup or testing.

Vague Triggers

Medium

• Confidence: 96% confidence
• Finding: The README advertises a very broad chat trigger such as 'Update my servers' and says it 'just works', which creates weak activation boundaries for a high-impact skill. In an agent environment, ordinary conversational text can unintentionally invoke live patching across multiple hosts and container workloads, increasing the chance of accidental execution.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

# 3. Configure PatchMon credentials
cp scripts/patchmon-credentials.example.conf ~/.patchmon-credentials.conf
nano ~/.patchmon-credentials.conf
chmod 600 ~/.patchmon-credentials.conf

# 4. Test with dry-run
scripts/patch-auto.sh --dry-run

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

# 3. Configure PatchMon credentials
cp scripts/patchmon-credentials.example.conf ~/.patchmon-credentials.conf
nano ~/.patchmon-credentials.conf
chmod 600 ~/.patchmon-credentials.conf

# 4. Test with dry-run
scripts/patch-auto.sh --dry-run

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

# 3. Configure PatchMon credentials
cp scripts/patchmon-credentials.example.conf ~/.patchmon-credentials.conf
nano ~/.patchmon-credentials.conf
chmod 600 ~/.patchmon-credentials.conf

# 4. Test with dry-run
scripts/patch-auto.sh --dry-run

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Vague Triggers

Medium

• Confidence: 93% confidence
• Finding: The usage section presents natural-language examples like 'Update my servers' and 'What servers need patching?' without clear activation boundaries or explicit confirmation requirements. Because this skill performs operational changes, ambiguous examples increase the risk that a user, another tool, or prompt-injected content triggers patching unintentionally.

Static analysis

No suspicious patterns detected.