Back to skill

Security audit

Incident Hotfix

Security checks for vulnerabilities and agentic risk

Overview

The skill fits its incident-hotfix purpose, but its helper scripts can write outside the intended incident folder and can save GitHub environment values into repo evidence files.

Review or patch the scripts before use. Use only simple incident IDs like INC-1234, do not run evidence capture in a shell or CI job containing GitHub tokens or other secrets, and inspect generated evidence files before committing, uploading, or sharing them.

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

T09 · Insecure Skill Coding Practices

Error
Location
scripts/start_hotfix.sh:20
Finding
Unvalidated Incident ID Enables Arbitrary Path Traversal and File Overwrite<![CDATA[ ## Vulnerability Details **File Location**: `scripts/start_hotfix.sh:20-38`; `scripts/capture_evidence.sh:17-24` **Vulnerability Type**: Path traversal and arbitrary file placement **Risk Level**: High ### Vulnerable Code From `scripts/start_hotfix.sh:20-38`: ```bash SLUG=$(echo "$ID" | tr '[:upper:]' '[:lower:]' | tr -cd 'a-z0-9-') BRANCH="hotfix/${SLUG}" mkdir -p "docs/incidents/${ID}/evidence" cat > "docs/incidents/${ID}/TIMELINE.md" <<EOF # ${ID} Timeline - Detected: - Impact: - Mitigation started: - Fixed in commit: - Verified at: EOF cat > "docs/incidents/${ID}/ROLLBACK.md" <<EOF # ${ID} Rollback Plan - Trigger conditions: - Rollback command: - Data considerations: - Verification steps: EOF ``` From `scripts/capture_evidence.sh:17-24`: ```bash OUT="docs/incidents/${ID}/evidence" mkdir -p "$OUT" if git rev-parse --is-inside-work-tree >/dev/null 2>&1; then git status --short > "$OUT/git-status.txt" || true git log --oneline -n 30 > "$OUT/git-log.txt" || true git diff --stat > "$OUT/diff-stat.txt" || true git diff --name-only > "$OUT/changed-files.txt" || true fi ``` ### Technical Analysis Both scripts accept an incident identifier through `--id` and embed it directly in filesystem paths. Although the variables are quoted, quoting only prevents shell word splitting and glob expansion; it does not prevent path traversal through `../` components or absolute-path-like constructions. The scripts do not enforce the documented `INC-1234` format, canonicalize the resulting path, or verify that it remains beneath `docs/incidents/`. The sanitized `SLUG` variable is used only for the Git branch name and therefore does not protect the paths constructed from the original `ID`. The `start_hotfix.sh` script uses truncating redirections for predictable filenames, allowing existing writable files at resolved target paths to be overwritten. The evidence script similarly creates a destination controlled by the supplied identifier and writes Git ...[truncated 1490 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Enforce a strict incident-ID allowlist before using the value: ```bash if [[ ! "$ID" =~ ^INC-[0-9]+$ ]]; then echo "Invalid incident ID; expected INC- followed by digits" >&2 exit 1 fi ``` 2. Explicitly reject path separators, `.` components, control characters, and empty sanitized identifiers. 3. Resolve the intended root and output directory to canonical paths, then verify that the output remains beneath the incident root. 4. Use the validated or sanitized identifier consistently for both branch names and filesystem paths. 5. Avoid silently overwriting existing incident files. Use no-clobber behavior, test for existing files, or require explicit overwrite confirmation. 6. Consider restrictive directory permissions, such as `umask 077`, before creating incident evidence. 7. Add automated tests covering `../`, absolute paths, repeated separators, control characters, empty values, and valid incident identifiers. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/capture_evidence.sh:26
Finding
Overbroad Environment Capture May Persist GitHub Credentials<![CDATA[ ## Vulnerability Details **File Location**: `scripts/capture_evidence.sh:26` **Vulnerability Type**: Sensitive information exposure through environment-variable capture **Risk Level**: Medium ### Vulnerable Code ```bash ( env | grep -E '^(NODE_ENV|ENV|APP_ENV|CI|GITHUB_)' || true ) > "$OUT/env-safe.txt" ``` ### Technical Analysis The script describes the output as a safe environment snapshot, but the expression allows every environment variable whose name begins with `GITHUB_`. This is a prefix-based selection rather than an explicit allowlist of known non-sensitive variables. Execution environments may contain sensitive variables such as `GITHUB_TOKEN` or custom credentials using the `GITHUB_` prefix. If present, both the variable name and plaintext value are copied into `env-safe.txt`. The file is stored under `docs/incidents/<id>/evidence/`, which is inside the repository workspace. Incident evidence may later be committed, uploaded as a CI artifact, attached to a ticket, or shared with responders. The reviewed script does not itself transmit the file over the network, but it creates a durable plaintext copy that can be exposed through normal evidence-handling workflows. ### Attack Path 1. The script runs in a developer shell or CI environment containing a sensitive variable with a matching name, such as `GITHUB_TOKEN`. 2. `env` emits the variable and its plaintext value. 3. The broad `grep` expression accepts the variable because its name starts with `GITHUB_`. 4. The complete value is written to `docs/incidents/<id>/evidence/env-safe.txt`. 5. A user or automated process commits, archives, uploads, or shares the evidence directory. 6. Anyone with access to that destination can retrieve the credential and use it until it expires or is revoked. ### Impact Assessment The script does not obtain additional system privileges by itself. The potential privilege and scope of a subsequent compromise are determined by the exposed credential. A leak ...[truncated 497 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace the prefix match with an explicit allowlist of known non-sensitive names, for example: ```bash for name in NODE_ENV APP_ENV CI GITHUB_ACTIONS GITHUB_EVENT_NAME GITHUB_REF GITHUB_SHA; do if [[ -v "$name" ]]; then printf '%s=%s\n' "$name" "${!name}" fi done > "$OUT/env-safe.txt" ``` 2. Never collect variables whose names contain patterns such as `TOKEN`, `SECRET`, `PASSWORD`, `PASS`, `KEY`, `CREDENTIAL`, or `AUTH`. 3. Apply a second redaction pass before writing the evidence file, so an accidental allowlist expansion cannot immediately expose secrets. 4. Set a restrictive `umask`, such as `077`, before creating evidence files. 5. Prevent generated evidence from being committed by default, or document a mandatory secret scan before evidence is uploaded or shared. 6. Add tests that populate representative sensitive variables, including `GITHUB_TOKEN`, and verify that neither their names nor values appear in the output. 7. If existing evidence bundles may have been generated in credential-bearing environments, inspect them securely and rotate any credentials found. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (1)

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The skill instructs users to run an evidence-capture script that writes incident artifacts and collects a local environment snapshot, but it does not warn that this may gather sensitive local data or modify the repository by creating forensic documentation. In an incident context, operators may run such commands quickly under pressure, increasing the chance of unintentionally collecting secrets, host details, or other sensitive metadata into tracked files or sharable evidence bundles.

Static analysis

No suspicious patterns detected.