T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:14- Finding
Mutable Remote Installation Script Is Executed Directly by a Shell
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill has a coherent identity-linking purpose, but it handles wallet secrets and private signing keys with risky install, storage, and publishing patterns that deserve manual review before use.
Review this skill carefully before installing. Use it only in an isolated environment, avoid running the curl|sh installer, pin and audit dependencies first, do not expose the nsec in terminal logs or command arguments, and do not publish DID/profile data to relays unless you intentionally want that public linkage.
SKILL.md:14Mutable Remote Installation Script Is Executed Directly by a Shell
scripts/derive-nostr.sh:9Unpinned npm and npx Dependencies Execute While Wallet Secrets Are Accessible
scripts/derive-nostr.sh:7Predictable Shared Temporary Directory Permits Local Module Substitution
scripts/derive-nostr.sh:29Unescaped Mnemonic Is Interpolated into Executable JavaScript Source
SKILL.md:43Nostr Private Key Is Exposed Through the Process Argument Vector
The stated purpose is key derivation/unification, but the documented behavior extends into secret extraction/output and runtime package installation. That mismatch is dangerous because users may consent to a narrow identity operation while the workflow handles and exposes highly sensitive material and pulls additional code from external sources.
The script prints the derived nsec private key to stdout, which exposes secret key material to terminal history, logs, shell capture, calling processes, CI output, or transcript systems. In this skill's context, the output is directly derived from the user's Archon mnemonic, so disclosure enables complete impersonation and loss of control over the linked Nostr identity.
The instructions explicitly output and persist the Nostr private key (nsec) to disk without strong warnings, safer alternatives, or lifecycle guidance. Exposing the secret in shell history, terminal logs, or a predictable file path can lead to account takeover and permanent compromise of the linked identity.
Creating a persistent directory and storing the derived nsec there causes long-lived secret retention on disk. In the context of a private signing key that links DID and Nostr identities, persistence significantly increases the blast radius of local compromise, backups, malware, or accidental disclosure.
mkdir -p ~/.clawstr
# Save the nsec output from above
echo "nsec1..." > ~/.clawstr/secret.key
chmod 600 ~/.clawstr/secret.key
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
mkdir -p ~/.clawstr
echo "nsec1..." > ~/.clawstr/secret.key chmod 600 ~/.clawstr/secret.key
## Update DID Document
The skill claims to derive a Nostr identity, but it also instructs users to mutate DID state and publish to external relays. This broadens the trust boundary from local derivation to persistent identity changes and public network actions, increasing the chance of unintended disclosure or irreversible mistakes.
Using npx @didcid/keymaster without pinning a specific version causes the latest package version to be fetched and executed at runtime. This creates supply-chain risk and makes behavior non-reproducible; a compromised or malicious upstream release could change or exfiltrate wallet-related data in a workflow already handling identity metadata.
Publishing profile data to public Nostr relays is not necessary to derive or unify keys, so it introduces extra exposure unrelated to the core purpose. In context, this is more dangerous because the same workflow also handles a private key, creating a direct path from derivation to public broadcasting.
The workflow publishes profile content to public relays without an explicit warning that the transmission is public, networked, and potentially permanent. Users may unintentionally disclose identifying information, especially since the sample content links a DID to a Nostr profile.
The unpinned npx @didcid/keymaster invocation executes whatever current version npm resolves, which is risky in a security-sensitive identity workflow. Because this skill operates adjacent to DID and key material, upstream package compromise could have outsized consequences.
The script depends on npx @didcid/keymaster without pinning an exact version, so execution may fetch and run whatever package version is current at runtime. In a skill that retrieves a wallet mnemonic and derives private key material, a compromised or malicious upstream release would directly expose seed phrases and derived secrets, making the unpinned dependency especially dangerous.
At the point where the mnemonic is fetched, the script actively executes npx @didcid/keymaster show-mnemonic without version pinning, meaning untrusted code can run immediately before handling the most sensitive secret in the workflow. If the package supply chain is compromised, the mnemonic can be exfiltrated at the exact moment it is accessed, leading to total wallet compromise.
Piping a remote script from GitHub directly into sh executes unreviewed code immediately and inherits the user's environment, which may include sensitive variables such as ARCHON_PASSPHRASE. In a skill dealing with wallets and derived private keys, this supply-chain pattern is especially dangerous because compromise of the script source can lead to secret theft or arbitrary code execution.
- Archon wallet with existing DID
- `ARCHON_PASSPHRASE` environment variable set
- `nak` CLI: `curl -sSL https://raw.githubusercontent.com/fiatjaf/nak/master/install.sh | sh`
## Derive Keys
No suspicious patterns detected.