Complete Agent Backup

• Outcome: Review
• Latest audit: Sep 15, 2026 · 1:46 AM UTC
• Version: 1.0.0

Overview

This appears to be a real backup tool, but it needs Review because it handles credentials and executable agent state with unsafe restore and encryption behavior.

Review this before installing. Treat its backup files as containing passwords, tokens, conversations, and executable agent components. Do not restore archives from anyone you do not fully trust, do not rely on configured encryption unless you explicitly pass --encrypt, and do not use cloud upload without auditing the uploader and destination.

A.I.G

Vulnerability Patterns

• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• Tool Hijacking and Spoofing: Modifies or replaces tools so legitimate-looking calls execute attacker logic
• 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 (5)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/restore.sh:61
• Finding: Unvalidated archive extraction permits writes outside the restore directory<![CDATA[ ## Vulnerability Details **File Location**: `scripts/restore.sh:61-69` **Vulnerability Type**: Untrusted archive extraction **Risk Level**: High ### Vulnerable Code ```bash WORK_DIR="/tmp/hermes-restore-$$" mkdir -p "$WORK_DIR" trap "rm -rf $WORK_DIR" EXIT info "Extracting archive..." tar -xzf "$ARCHIVE" -C "$WORK_DIR" BACKUP_DIR=$(find "$WORK_DIR" -maxdepth 1 -name "hermes-backup_*" -type d | head -1) [[ -z "$BACKUP_DIR" ]] && error "Invalid archive: no hermes-backup_* directory found" ``` ### Technical Analysis The restore script extracts an attacker-controlled archive before validating its entries. It does not reject: - Absolute paths - Paths containing `..` - Symbolic or hard links pointing outside the extraction directory - Device files, FIFOs, or other unexpected entry types - Multiple or unexpected top-level directories Checking for a directory named `hermes-backup_*` after extraction does not make the other archive entries safe. The extraction also occurs during `--dry-run`, even though that mode states that no changes will be made. Depending on the host `tar` implementation and archive structure, malicious entries or link-based extraction sequences may write outside the intended temporary directory. ### Attack Path 1. An attacker creates a backup archive containing the expected `hermes-backup_*` directory and malicious traversal or link entries. 2. The attacker convinces a user to inspect or restore the archive. 3. The user invokes `restore.sh`, potentially with `--dry-run`. 4. `tar -xzf` processes all archive members before the manifest or directory structure is validated. 5. Malicious members write or redirect files outside the intended restore directory. 6. The overwritten file may subsequently expose data, alter configuration, or execute code when loaded by the user or agent platform. ### Impact Assessment Successful exploitation operates with the privileges of the user running the restore command. It may permit modification o ...[truncated 204 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. List all archive members before extraction and reject entries that: - Are absolute paths - Contain `..` path components - Resolve outside the extraction root - Are device files, FIFOs, or other unsupported types - Contain unsafe symbolic or hard links 2. Require exactly one expected top-level directory. 3. Extract into a directory created with `mktemp -d` under a restrictive `umask`. 4. Use extraction options that prevent ownership and permission restoration, such as `--no-same-owner` and `--no-same-permissions`, where supported. 5. Validate the manifest and archive structure before performing the actual extraction. 6. Ensure dry-run mode only lists and validates archive members and never extracts them. 7. Cryptographically authenticate backups before processing them. ]]>

T06 · System Persistence

Error

• Location: scripts/restore.sh:166
• Finding: Restore imports untrusted executable scripts, skills, and persistent cron state<![CDATA[ ## Vulnerability Details **File Location**: `scripts/restore.sh:166-176` **Vulnerability Type**: Untrusted executable and persistent-state restoration **Risk Level**: High ### Vulnerable Code ```bash [[ -d "${BACKUP_DIR}/skills" ]] && restore_item "${BACKUP_DIR}/skills/" "${TARGET_HOME}/skills" "skills" [[ -f "${BACKUP_DIR}/state.db" ]] && restore_item "${BACKUP_DIR}/state.db" "${TARGET_HOME}/state.db" "state.db" [[ -f "${BACKUP_DIR}/auth.json" ]] && restore_item "${BACKUP_DIR}/auth.json" "${TARGET_HOME}/auth.json" "auth.json" else # OpenClaw-specific files [[ -d "${BACKUP_DIR}/config" ]] && restore_item "${BACKUP_DIR}/config/openclaw.json" "${TARGET_HOME}/openclaw.json" "openclaw.json" [[ -d "${BACKUP_DIR}/credentials" ]] && restore_item "${BACKUP_DIR}/credentials/" "${TARGET_HOME}/credentials" "credentials" [[ -d "${BACKUP_DIR}/channels" ]] && restore_item "${BACKUP_DIR}/channels/" "${TARGET_HOME}/" "channel state" [[ -d "${BACKUP_DIR}/agents" ]] && restore_item "${BACKUP_DIR}/agents/" "${TARGET_HOME}/agents" "agents" [[ -d "${BACKUP_DIR}/skills-system" ]] && restore_item "${BACKUP_DIR}/skills-system/" "${TARGET_HOME}/skills" "system skills" [[ -d "${BACKUP_DIR}/cron" ]] && restore_item "${BACKUP_DIR}/cron/" "${TARGET_HOME}/cron" "cron" [[ -d "${BACKUP_DIR}/scripts" ]] && restore_item "${BACKUP_DIR}/scripts/" "${TARGET_HOME}/" "scripts" fi ``` ### Technical Analysis The restore process treats archive contents as trusted and copies them into operational platform directories. This includes: - Installed skills - Gateway and guardian scripts - Scheduled-job state - Agent state and session data - Credentials and channel state No signature, authenticated checksum, trusted-source check, executable-content review, or component-level confirmation is performed. Restored scripts retain metadata through `rsync -a`, potentially including executable permissions. Restored cron state can survive the restore operation and may be consumed by the ...[truncated 1226 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Authenticate backup archives using a digital signature or a keyed integrity mechanism before restoration. 2. Exclude executable scripts, skills, and cron state from the default restore set. 3. Require explicit, separate confirmation for each executable or persistent component. 4. Display file paths, hashes, permissions, and differences before installation. 5. Restore scripts without executable permissions and restore scheduled jobs in a disabled state pending review. 6. Enforce an allowlist of expected filenames and component types. 7. Reject archives containing unexpected executables, links, or persistent configuration. 8. Document that archives must be treated as executable software rather than passive data. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/restore.sh:50
• Finding: Predictable temporary paths expose plaintext credentials and decrypted backups<![CDATA[ ## Vulnerability Details **File Location**: `scripts/restore.sh:50-64` **Additional Locations**: `scripts/backup.sh:91-94`, `scripts/backup.sh:110-112`, `scripts/backup.sh:171-173`, `scripts/backup.sh:270-286` **Vulnerability Type**: Unsafe temporary-file handling **Risk Level**: High ### Vulnerable Code ```bash TEMP_ARCHIVE="/tmp/hermes-restore-$$.tar.gz" if ! openssl enc -aes-256-cbc -d -salt -pbkdf2 -in "$ARCHIVE" -out "$TEMP_ARCHIVE" -pass pass:"$PASSWORD" 2>/dev/null; then error "Decryption failed — wrong password?" fi ARCHIVE="$TEMP_ARCHIVE" trap "rm -f $TEMP_ARCHIVE" EXIT fi # ── Extract and validate ───────────────────────────────────────────────────── WORK_DIR="/tmp/hermes-restore-$$" mkdir -p "$WORK_DIR" trap "rm -rf $WORK_DIR" EXIT ``` The backup script similarly creates a predictable temporary directory and copies credentials into it: ```bash WORK_DIR="/tmp/${BACKUP_NAME}" ARCHIVE="${BACKUP_DIR}/${BACKUP_NAME}.tar.gz" mkdir -p "$BACKUP_DIR" "$WORK_DIR" ``` ```bash if [[ -f "${PLATFORM_HOME}/.env" ]]; then cp "${PLATFORM_HOME}/.env" "${WORK_DIR}/config/" info " .env (secrets)" fi ``` ```bash if [[ -d "${PLATFORM_HOME}/credentials" ]]; then mkdir -p "${WORK_DIR}/credentials" rsync -a "${PLATFORM_HOME}/credentials/" "${WORK_DIR}/credentials/" info " credentials" fi ``` ### Technical Analysis The scripts use predictable names under the shared `/tmp` directory instead of securely creating unique temporary files and directories with `mktemp`. They also do not set a restrictive `umask` before copying credentials, API keys, sessions, and decrypted archive content. In `restore.sh`, the cleanup trap for `TEMP_ARCHIVE` is replaced by the later trap for `WORK_DIR`. Consequently, the decrypted plaintext archive may remain in `/tmp` after the script exits. The decryption password is supplied through the `openssl` command-line argument: ```bash -pass pass:"$PASSWORD" ``` On systems exposing process arguments to other users, t ...[truncated 1072 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Set `umask 077` at the beginning of every script that handles sensitive data. 2. Create temporary directories with `mktemp -d` and temporary files with `mktemp`. 3. Reject or safely handle any pre-existing temporary path. 4. Register one cleanup function that removes every temporary artifact, then install a single quoted trap: ```bash cleanup() { rm -f -- "${TEMP_ARCHIVE:-}" rm -rf -- "${WORK_DIR:-}" } trap cleanup EXIT INT TERM ``` 5. Avoid placing decrypted archives on disk where possible; otherwise ensure they are created with mode `0600`. 6. Do not pass passwords in process arguments. Use a protected file descriptor or another supported non-command-line password input mechanism. 7. Create the destination archive with restrictive permissions from inception rather than applying `chmod 600` only after packaging and encryption. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/backup.sh:7
• Finding: Configured encryption is ignored when creating backups<![CDATA[ ## Vulnerability Details **File Location**: `scripts/backup.sh:7-10` **Additional Locations**: `scripts/backup.sh:59-68`, `scripts/backup.sh:273-286`, `scripts/config.sh:83-96`, `scripts/config.sh:166-176` **Vulnerability Type**: Security configuration not enforced **Risk Level**: High ### Vulnerable Code The backup script always initializes encryption as disabled: ```bash BACKUP_TYPE="full" ENCRYPT=false CLOUD_UPLOAD=false TAG="" QUIET=false ``` Its configuration parser does not read the encryption setting: ```bash CONFIG_FILE="${HOME}/.hermes-backup/config.yaml" if [[ -f "$CONFIG_FILE" ]]; then BACKUP_DIR=$(grep "location:" "$CONFIG_FILE" | head -1 | cut -d':' -f2- | xargs | sed "s|~|$HOME|") KEEP_COUNT=$(grep "keep_count:" "$CONFIG_FILE" | head -1 | cut -d':' -f2 | xargs) else BACKUP_DIR="${HOME}/backups/hermes" KEEP_COUNT=10 fi ``` Encryption occurs only when the command-line flag changes `ENCRYPT`: ```bash if [[ "$ENCRYPT" == true ]]; then [[ "$QUIET" == false ]] && echo "" warn "Encryption enabled — you MUST remember this password!" openssl enc -aes-256-cbc -salt -pbkdf2 -in "$ARCHIVE" -out "${ARCHIVE}.enc" rm "$ARCHIVE" ARCHIVE="${ARCHIVE}.enc" info "Encrypted: ${ARCHIVE}" fi ``` However, the configuration wizard tells the user that encryption applies to all backups and writes the setting: ```bash if [[ "$ENCRYPT_CHOICE" == "2" ]]; then ENCRYPT="true" warn "⚠️ IMPORTANT: If you lose the password, backups are UNRECOVERABLE!" warn "Store the password in a password manager (1Password, Bitwarden, etc.)" info "Encryption enabled" else ENCRYPT="false" info "Encryption disabled" fi ``` ```bash backup: location: ${BACKUP_DIR} type: ${BACKUP_TYPE} compression: gzip encryption: ${ENCRYPT} ``` ### Technical Analysis The configuration wizard represents encryption as a persistent setting, but `backup.sh` reads only the backup location and retention count. Unless `--encrypt` is supplied for each execution ...[truncated 1267 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Parse the configuration with a proper YAML parser rather than `grep`, `cut`, and `xargs`. 2. Load and honor `backup.encryption` for every backup invocation. 3. Make command-line flags explicit overrides of the configured value. 4. Fail closed if encryption is configured but cannot be performed. 5. Verify that the final artifact has the expected encrypted format before cloud upload. 6. Warn prominently and require explicit confirmation before creating an unencrypted archive containing credentials. 7. Add automated tests proving that `encryption: true` never produces a plaintext `.tar.gz` output. 8. Update scheduled-backup guidance to use a noninteractive and securely managed encryption-key mechanism. ]]>

T07 · Tool Hijacking and Spoofing

Warning

• Location: scripts/backup.sh:298
• Finding: Cloud upload executes an unverified user-writable external script<![CDATA[ ## Vulnerability Details **File Location**: `scripts/backup.sh:298-306` **Vulnerability Type**: External tool hijacking **Risk Level**: Medium ### Vulnerable Code ```bash if [[ "$CLOUD_UPLOAD" == true ]]; then if [[ -f "${HOME}/.hermes-backup/cloud-config.sh" ]]; then [[ "$QUIET" == false ]] && echo "" info "Uploading to cloud..." bash "${HOME}/.hermes-backup/cloud-upload.sh" "$ARCHIVE" else warn "Cloud not configured — run: hermes-backup cloud setup" fi fi ``` ### Technical Analysis The script checks for `cloud-config.sh` but executes a different file, `cloud-upload.sh`. It performs no validation of the executed file's: - Existence - Ownership - Permissions - Integrity - Provenance - Upload destination Both paths are under the user's writable home directory. If another process or compromised component replaces `cloud-upload.sh`, invoking `backup.sh --cloud-upload` executes the replacement through `bash`. The archive path is passed directly to that script, giving the external code immediate access to an archive containing credentials and private agent data. ### Attack Path 1. An attacker with the ability to write into `~/.hermes-backup` creates or replaces `cloud-upload.sh`. 2. The attacker ensures that `cloud-config.sh` exists so the unrelated existence check succeeds. 3. The user or a scheduled task runs `backup.sh --cloud-upload`. 4. The backup script invokes the attacker-controlled file with `bash`. 5. The malicious uploader reads or exfiltrates the generated credential archive and executes additional commands with the user's privileges. ### Impact Assessment The substituted script gains arbitrary command execution as the account running the backup. It can access the newly generated archive, API credentials, sessions, workspace data, SSH material available to the account, and other user-readable files. If invoked by a scheduled task, the malicious script may execute repeatedly. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Check the existence and type of the exact file that will be executed. 2. Package the cloud uploader as part of the audited project instead of loading it from a mutable configuration directory. 3. Verify that the uploader is a regular file owned by the expected user and not writable by group or others. 4. Verify the uploader against a trusted checksum or signature before execution. 5. Restrict the configuration directory to mode `0700` and sensitive files to mode `0600`. 6. Use explicit provider commands with validated arguments and destination allowlists rather than delegating the archive to an arbitrary shell script. 7. Refuse cloud upload when the archive is expected to be encrypted but is not encrypted. 8. Log the selected provider and destination without exposing credentials. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration

Findings (19)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence
• Finding: A second independent mismatch is present: the document centers on a full backup platform, yet no actual executable implementation is shown here and static analysis reports major missing functionality. In a backup product, unsupported claims are security-relevant because users may assume recoverability, confidentiality, and off-site protection that are not real.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 96% confidence
• Finding: A second independent mismatch is present: the document centers on a full backup platform, yet no actual executable implementation is shown here and static analysis reports major missing functionality. In a backup product, unsupported claims are security-relevant because users may assume recoverability, confidentiality, and off-site protection that are not real.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

### Security Best Practices

1. **File Permissions**
   - Backups created with `chmod 600` (owner only)
   - Never `chmod 777` a backup

2. **Storage**

• Confidence: 80% 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

fi
  
  # Environment (secrets)
  if [[ -f "${PLATFORM_HOME}/.env" ]]; then
    cp "${PLATFORM_HOME}/.env" "${WORK_DIR}/config/"
    info "  .env (secrets)"
  fi

• Confidence: 97% confidence
• Finding: This backup tool intentionally copies a .env file containing secrets into the backup set. While expected for a backup utility, it materially increases the sensitivity of the produced archive and magnifies the impact of any weakness in storage, encryption, upload, or retention handling.

Credential Access

High

• Category: Privilege Escalation

Content

# Environment (secrets)
  if [[ -f "${PLATFORM_HOME}/.env" ]]; then
    cp "${PLATFORM_HOME}/.env" "${WORK_DIR}/config/"
    info "  .env (secrets)"
  fi

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

Credential Access

High

• Category: Privilege Escalation

Content

# Environment (secrets)
  if [[ -f "${PLATFORM_HOME}/.env" ]]; then
    cp "${PLATFORM_HOME}/.env" "${WORK_DIR}/config/"
    info "  .env (secrets)"
  fi
  
  # Identity

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

Chaining Abuse

High

• Category: Tool Misuse

Content

BACKUP_COUNT=$(ls -t "${BACKUP_DIR}"/hermes-backup_*.tar.gz* 2>/dev/null | wc -l)
if [[ "$BACKUP_COUNT" -gt "$KEEP_COUNT" ]]; then
  info "Pruning old backups (keeping last ${KEEP_COUNT})..."
  ls -t "${BACKUP_DIR}"/hermes-backup_*.tar.gz* | tail -n +$((KEEP_COUNT + 1)) | xargs rm -f
  info "  Removed $((BACKUP_COUNT - KEEP_COUNT)) old backup(s)"
fi

• Confidence: 91% confidence
• Finding: Using ls output piped to xargs rm is unsafe because filenames can contain whitespace, newlines, or leading dashes, causing incorrect deletion targets or option confusion. Since BACKUP_DIR comes from a user-controlled config file, malformed or adversarial filenames in that directory could make pruning delete unintended files matching the glob selection behavior.

Credential Access

High

• Category: Privilege Escalation

Content

if [[ "$TARGET_PLATFORM" == "hermes" ]]; then
  # Hermes-specific files
  [[ -d "${BACKUP_DIR}/config" ]] && restore_item "${BACKUP_DIR}/config/config.yaml" "${TARGET_HOME}/config.yaml" "config.yaml"
  [[ -f "${BACKUP_DIR}/config/.env" ]] && restore_item "${BACKUP_DIR}/config/.env" "${TARGET_HOME}/.env" ".env"
  [[ -d "${BACKUP_DIR}/identity" ]] && restore_item "${BACKUP_DIR}/identity/SOUL.md" "${TARGET_HOME}/SOUL.md" "SOUL.md"
  [[ -d "${BACKUP_DIR}/memories" ]] && restore_item "${BACKUP_DIR}/memories/" "${TARGET_HOME}/memories" "memories"
  [[ -d "${BACKUP_DIR}/sessions" ]] && restore_item "${BACKUP_DIR}/sessions/" "${TARGET_HOME}/sessions" "sessions"

• Confidence: 87% confidence
• Finding: The restore logic restores a backed-up .env file directly into the agent home, which commonly contains API keys, tokens, and other secrets. Because the archive is extracted and its contents are trusted without authenticity verification or content validation, a tampered backup can inject attacker-controlled credentials or configuration, leading to account compromise, data exfiltration, or redirection of the agent to attacker infrastructure.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 89% confidence
• Finding: The skill advertises and instructs use of shell-capable operations but declares no explicit tool scope or permission boundaries. For a backup skill that handles secrets, filesystem access, restore actions, and cloud configuration, missing tool restrictions increases the chance of overbroad execution or accidental invocation with more access than intended.

Vague Triggers

Medium

• Confidence: 91% confidence
• Finding: The natural-language trigger 'Create a backup of my agent' is broad and could cause unintended invocation in ordinary conversation. In the context of a skill that archives highly sensitive files, accidental triggering could collect secrets, sessions, and workspace contents without the user intending to start a backup operation.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

1. **File Permissions**
   - Backups created with `chmod 600` (owner only)
   - Never `chmod 777` a backup

2. **Storage**
   - Keep local backups in encrypted disk/VeraCrypt

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

File System Enumeration

Medium

• Category: Data Exfiltration

Content

### "Permission denied" on backup
```bash
# Check directory permissions
ls -la ~/backups/hermes/

# Fix
chmod 700 ~/backups/hermes/

• Confidence: 60% confidence
• Finding: Code scans file system directories looking for sensitive files. This could be reconnaissance for credential theft.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

ls -la ~/backups/hermes/

# Fix
chmod 700 ~/backups/hermes/
```

### "Backup is corrupted"

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

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The script creates a plaintext tar.gz archive containing highly sensitive material such as .env files, auth.json, tokens, credentials, sessions, and state before encryption is optionally applied. This leaves secrets exposed by default and also creates a window where sensitive data exists unencrypted on disk, which is especially risky on shared systems, compromised hosts, or if the backup directory is synced or monitored.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The script can upload archives that contain credentials and conversation/session data to cloud storage without enforcing encryption or presenting a strong confirmation about remote transmission of secrets. If cloud configuration is insecure, misdirected, or compromised, this can lead to broad disclosure of sensitive agent data and authentication material.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

AUTO_BACKUP="/tmp/hermes-pre-restore-$(date +%Y%m%d_%H%M%S).tar.gz"
  warn "Creating safety backup of current state..."
  tar -czf "$AUTO_BACKUP" -C "$HOME" ".${TARGET_PLATFORM}" 2>/dev/null || true
  chmod 600 "$AUTO_BACKUP"
  info "Safety backup: $AUTO_BACKUP"
  echo ""
fi

• 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

AUTO_BACKUP="/tmp/hermes-pre-restore-$(date +%Y%m%d_%H%M%S).tar.gz"
  warn "Creating safety backup of current state..."
  tar -czf "$AUTO_BACKUP" -C "$HOME" ".${TARGET_PLATFORM}" 2>/dev/null || true
  chmod 600 "$AUTO_BACKUP"
  info "Safety backup: $AUTO_BACKUP"
  echo ""
fi

• 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

AUTO_BACKUP="/tmp/hermes-pre-restore-$(date +%Y%m%d_%H%M%S).tar.gz"
  warn "Creating safety backup of current state..."
  tar -czf "$AUTO_BACKUP" -C "$HOME" ".${TARGET_PLATFORM}" 2>/dev/null || true
  chmod 600 "$AUTO_BACKUP"
  info "Safety backup: $AUTO_BACKUP"
  echo ""
fi

• 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

AUTO_BACKUP="/tmp/hermes-pre-restore-$(date +%Y%m%d_%H%M%S).tar.gz"
  warn "Creating safety backup of current state..."
  tar -czf "$AUTO_BACKUP" -C "$HOME" ".${TARGET_PLATFORM}" 2>/dev/null || true
  chmod 600 "$AUTO_BACKUP"
  info "Safety backup: $AUTO_BACKUP"
  echo ""
fi

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

Static analysis

No suspicious patterns detected.