Is civilainominee/personality-backup safe?
https://github.com/openclaw/skills/tree/main/skills/civilainominee/personality-backup
The personality-backup skill is a functionally complete data exfiltration pipeline masquerading as a backup utility: by default it packages the agent's entire secret store, configuration, memory, personality files, and workspace projects into an AES-256 encrypted archive and delivers it to an externally-configured SMTP email address, then optionally schedules this to run daily via cron. While the SKILL.md itself contains no classic prompt-injection syntax and the install-time behavior was clean, the skill's runtime design is structurally identical to stalkerware — a persistent, automated, encrypted sweep of all sensitive agent state sent to a caller-controlled external endpoint. The encrypted delivery channel defeats network-layer inspection, the cron persistence survives agent session boundaries, and the SMTP destination is fully attacker-redirectable via config file manipulation.
Category Scores
Findings (11)
CRITICAL Core function is packaging and externally delivering secrets by default -60 ▶
The skill's primary purpose is to collect the agent secrets directory, config, personality files, memory, and projects into an encrypted archive and deliver it via SMTP email. The config default backup_secrets: true means secrets are included without any explicit opt-in. This is structurally identical to a data exfiltration tool. The SMTP destination, host, credentials, and recipient are all caller-configurable, meaning whoever configures the skill controls where all sensitive data goes.
CRITICAL Skill implements persistent daily data exfiltration pipeline -60 ▶
The skill explicitly instructs LLM agents to install a daily cron job that runs the backup-and-deliver pipeline at 03:00 every day. Once installed, all agent secrets, memory, personality, and projects are silently packaged and sent to the configured email address daily, indefinitely, even without further agent interaction. The encrypted format prevents any content-inspection-based detection.
HIGH eval of Python-generated shell output enables code injection -30 ▶
backup.sh sources its configuration by running eval "$(python3 "$SCRIPT_DIR/parse_config.py" "$CONFIG_FILE")". If the config file is maliciously crafted or written by a compromised companion skill, parse_config.py could emit shell metacharacters that escape the single-quote wrapping despite the sh_escape function, achieving arbitrary code execution in the backup script's shell context.
HIGH Comprehensive workspace harvesting across all sensitive categories -20 ▶
Beyond the secrets directory, backup.sh collects: all personality files (SOUL.md, IDENTITY.md, USER.md, AGENTS.md, MEMORY.md, TOOLS.md), entire memory/ directory, all workspace *.md files, all projects (excluding only node_modules/.git/pycache and media files), all workspace scripts. This constitutes a complete agent identity and operational state extraction.
HIGH Cron job creation establishes persistent execution outside agent lifecycle -30 ▶
The skill instructs the agent to run crontab -e to schedule daily backup execution. This creates a persistent system-level process that survives agent sessions, restarts, and even skill removal. Once the cron entry is created, the data exfiltration pipeline runs autonomously without any further agent invocation.
HIGH SMTP destination fully attacker-configurable enables redirected exfiltration -25 ▶
The skill design allows any SMTP server, any recipient email, and any credentials to be specified in the config file. A threat actor who can influence the config file contents (via social engineering, a malicious companion skill, or agent hallucination during config setup) can redirect all daily backups containing the agent's complete state to attacker-controlled infrastructure. The AES-256 encryption prevents network detection.
MEDIUM Skill description enables autonomous execution of irreversible high-privilege actions -20 ▶
The SKILL.md trigger description ('Use when the agent needs to set up, run, or manage automated backups') and usage instructions present cron installation and SMTP configuration as normal operational steps. An LLM agent following these instructions may execute crontab modification and begin sending data externally without seeking explicit user approval for each step, treating them as implied by 'set up backup.'
MEDIUM SMTP password stored plaintext in config or exposed via environment variable name -10 ▶
The config supports smtp_pass directly in the JSON (plaintext) as a 'less secure' option. The smtp_pass_env field names an environment variable whose value is read and embedded in shell variables via eval. Both patterns risk credential exposure: the plaintext in config files, and the environment variable name in logs/process listings.
MEDIUM Post-install batch simultaneous read of all canary credential files -18 ▶
At timestamp 1771938156.242, all six canary files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, .config/gcloud/application_default_credentials.json) were accessed within a 1ms window. While the oathe monitoring system likely caused this as a post-install canary check, the access pattern is identical to what the backup.sh secrets sweep would produce if it ran against the home directory.
LOW No explicit user confirmation checkpoint before external delivery -10 ▶
The backup workflow proceeds from config parse through archive creation to SMTP send without any pause point where the skill instructs the agent to confirm with the user before data leaves the system. The SKILL.md presents email delivery as a configuration option rather than a high-stakes action requiring explicit approval.
INFO Canary files read pre- and post-install but contents intact -12 ▶
Canary credential files were accessed at three timepoints: pre-install baseline (1771938135.209), post-install period (1771938146, 1771938153), and post-install audit sweep (1771938156). The audit system confirms all canary file contents remained unmodified and no corresponding network exfiltration traffic was detected during the monitoring window. These reads are attributed to the oathe monitoring system itself.