T03 · Remote Payload Retrieval and Execution
- Location
scripts/quickstart.sh:6- Finding
Unverified Remote Script Execution Through curl-to-Bash Installation
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill’s memory-integrity purpose is coherent, but its installer guidance and quickstart introduce high-impact review concerns around remote shell execution, persistent agent-state changes, and retained copies of private memory files.
Review this before installing. Prefer the local scripts from the reviewed package and do not use the documented curl-to-bash command. Run setup only in a workspace where duplicating identity and memory Markdown files into .nix-memory is acceptable, and inspect or manually edit HEARTBEAT.md if you do not want recurring future execution.
scripts/quickstart.sh:6Unverified Remote Script Execution Through curl-to-Bash Installation
scripts/setup.sh:15Plaintext Duplication of Sensitive Identity and Memory Files
scripts/quickstart.sh:224Quickstart Permanently Adds Recurring Commands to Agent Heartbeat State
scripts/quickstart.sh:106Unescaped Workspace and Argument Data Written to JSON and JSONL
The usage instructions recommend fetching a remote script and piping it directly to bash, which enables arbitrary code execution from a network source with no integrity verification. If the remote host, transport, DNS, or upstream content is compromised, users would immediately execute attacker-controlled shell commands.
# Zero deps. Pure bash. Works everywhere.
#
# Usage:
# curl -sL https://nixus.pro/memory/install.sh | bash
# -- or --
# bash skills/nix-memory/scripts/quickstart.sh
#
Piping curl output directly into bash removes any opportunity for inspection and turns network-delivered content into immediate command execution. In an installer for agent skills, this is especially dangerous because it normalizes unsafe operator behavior and can lead to full workspace or account compromise if the fetched content is tampered with.
# Zero deps. Pure bash. Works everywhere.
#
# Usage:
# curl -sL https://nixus.pro/memory/install.sh | bash
# -- or --
# bash skills/nix-memory/scripts/quickstart.sh
#
The script automatically runs setup.sh when the expected state directory is missing, which can create or modify files in the workspace without explicit user confirmation. In an agent skill context, implicit filesystem-changing behavior increases risk because initialization may occur as a side effect of a read-like health check, and users may not realize execution will mutate their environment.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
echo " Last verification: ${LATEST_AGE} hours ago"
if [[ $LATEST_AGE -gt 48 ]]; then
SCORE=$((SCORE - 10))
echo " WARNING: No verification in ${LATEST_AGE}h - continuity gap"
fi
fi
fi
The header comments describe this script as an installer that sets up the complete memory architecture and list nix-memory and memory-guard among what it installs. In practice, the code only checks whether those skill directories already exist and, if not, emits warnings and continues, so the documented effect of a complete install is contradicted by the actual behavior.
The script executes other shell scripts from the workspace (setup.sh and memory-guard.sh) without verifying integrity, origin, or obtaining confirmation. In this context, the workspace is attacker-influenced input, so a malicious or replaced skill script would execute arbitrary code under the user's account during installation.
The installer creates and modifies multiple files in the user's workspace without an approval step, including agent.json, HEARTBEAT.md, and executable helper scripts. In a skill-install context, silent mutation of persistent workspace state is risky because users may run the installer expecting inspection or limited setup, while the script alters future agent behavior and trust-related metadata.
This code creates persistent directories and later writes multiple files under the state directory, including logs, manifests, config, and baseline snapshots. Although the script logs what it is doing, it does not provide a user-facing warning before creating persistent local state or copying tracked markdown files into baseline storage.
This block saves a continuity report to a file under the state directory, which is a filesystem write affecting persistent user or workspace data. The write is visible in code, but there is no preceding comment, header warning, or stronger user-facing notice explaining that running the script will store a report on disk.