Back to skill

Security audit

Simple File Backup

Security checks for vulnerabilities and agentic risk

Overview

This skill is a simple user-directed file backup helper, with a limited filename-safety caveat in shared directories.

Use this for ordinary local backups of files you choose. Avoid writing backups into shared or untrusted directories, because the timestamped filename format can be predicted and may overwrite an existing backup or interact poorly with symlinks.

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
run.sh:26
Finding

Predictable Backup Filename Allows Symlink-Based File Overwrite

Content
View full analysis

Vulnerability Details

File Location: run.sh, lines 26-30
Vulnerability Type: Predictable file creation and unsafe handling of an existing destination
Risk Level: Medium

Vulnerable Code

bash
BASENAME=$(basename "$FILE_PATH")
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="$BACKUP_DIR/${BASENAME}.backup_${TIMESTAMP}"

cp "$FILE_PATH" "$BACKUP_FILE"

Technical Analysis

The backup filename is derived from the source basename and a timestamp with one-second precision. The resulting path is predictable, and the script neither atomically reserves the destination nor verifies that it does not already exist or refer to a symbolic link.

If the selected backup directory is writable by another user, that user can predict the destination and create it as a symbolic link before cp executes. A normal cp operation can follow an existing destination symlink and write the source data to its target. The target must still be writable by the account running the script, so this issue does not independently bypass operating-system permissions.

The same naming scheme also causes two backups of the same source basename created within one second to use the same destination. The later operation can silently overwrite the earlier backup.

Attack Path

  1. A victim invokes run.sh with a shared or attacker-writable directory as BACKUP_DIR.
  2. The attacker learns or predicts the source basename and the second in which the script will run.
  3. The attacker creates the anticipated backup path, such as config.yaml.backup_20260328_143022, as a symbolic link to another file.
  4. The script constructs the same predictable destination without checking whether it already exists or is a symlink.
  5. cp writes through the destination symlink and replaces the target's contents with the source file, provided the victim's account can write to that target.

Exploitation therefore requires control of the backup director ...[truncated 665 chars]

Remediation
View remediation

Remediation Suggestions

  • Atomically create a unique destination inside the selected backup directory using mktemp, rather than constructing a predictable name and subsequently opening it.
  • Ensure the temporary destination is created in BACKUP_DIR itself so uniqueness and creation occur on the intended filesystem.
  • Reject unsafe backup directories, particularly directories writable by untrusted users, or explicitly document that such directories must not be used.
  • If a human-readable final name is required, reserve it atomically and fail rather than overwrite when it already exists. Do not use a check-then-copy sequence because it remains vulnerable to a time-of-check/time-of-use race.
  • Apply restrictive permissions appropriate for potentially sensitive source files and preserve the desired source metadata deliberately.
  • Add tests covering pre-existing files, destination symlinks, concurrent invocations, and multiple backups created within the same second.

A hardened implementation should use an atomically generated path, for example:

bash
BASENAME=$(basename -- "$FILE_PATH")
BACKUP_FILE=$(mktemp --tmpdir="$BACKUP_DIR" "${BASENAME}.backup_$(date +%Y%m%d_%H%M%S).XXXXXX")
chmod --reference="$FILE_PATH" "$BACKUP_FILE"
cp -- "$FILE_PATH" "$BACKUP_FILE"

Where supported, use copy options and file-creation APIs that explicitly reject symlink destinations and prevent clobbering. Any failure after reserving the file should also remove the incomplete backup.

Vulnerability Patterns
  • 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
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.