magic-wormhole

• Outcome: Review
• Latest audit: Sep 10, 2026 · 9:37 PM UTC
• Version: 1.0.0

Overview

This is a coherent magic-wormhole secret-sharing skill, but it includes examples that could expose credentials or create lasting privileged server access.

Review before installing. Do not give ClawHub or other account tokens directly to an agent, do not follow examples that send existing private keys or whole SSH directories, and do not run the remote root/sudoers setup unless you have explicitly reviewed and approved the exact target and access policy. Prefer dedicated short-lived credentials, recipient-generated SSH keys, password managers, out-of-band code verification, and secure temporary files created with mktemp and restrictive permissions.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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)

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: examples/ssh-key-sharing.md:167
• Finding: Remote Account Creation and Passwordless Sudo Delegation<![CDATA[ ## Vulnerability Details **File Location**: `examples/ssh-key-sharing.md:167-187` **Vulnerability Type**: Excessive remote privilege modification **Risk Level**: High ### Vulnerable Code ```bash # Configuration USERNAME="deploy" SERVER="production.example.com" TEMP_DIR="/tmp" print_status() { echo "[INFO] $1" } print_success() { echo "[SUCCESS] $1" } # 1. Create user on server (requires root access) print_status "Creating user $USERNAME on server..." ssh root@$SERVER "useradd -m -s /bin/bash $USERNAME" # 2. Generate SSH key print_status "Generating SSH key pair..." ssh-keygen -t ed25519 -f "$TEMP_DIR/$USERNAME-key" -C "$USERNAME@$SERVER" -N "" # 3. Send private key to human print_status "Sending private key via wormhole..." CODE=$(wormhole send --text "$(cat $TEMP_DIR/$USERNAME-key)" 2>&1 | grep "Wormhole code is:" | cut -d' ' -f4) # 4. Add public key to server print_status "Adding public key to server..." ssh root@$SERVER "mkdir -p /home/$USERNAME/.ssh && chmod 700 /home/$USERNAME/.ssh && echo '$(cat $TEMP_DIR/$USERNAME-key.pub)' > /home/$USERNAME/.ssh/authorized_keys && chmod 600 /home/$USERNAME/.ssh/authorized_keys && chown -R $USERNAME:$USERNAME /home/$USERNAME/.ssh" # 5. Grant sudo access (optional) print_status "Granting sudo access..." ssh root@$SERVER "echo '$USERNAME ALL=(ALL) NOPASSWD:/usr/bin/apt-get' >> /etc/sudoers.d/$USERNAME" ``` ### Technical Analysis The workflow does substantially more than transfer an SSH key. It connects to a remote server as `root`, creates a persistent login account, replaces that account's `authorized_keys`, and unconditionally installs a passwordless sudo rule. Although the comment calls sudo access optional, the command is executed without an option, confirmation prompt, or policy check. Allowing passwordless execution of `apt-get` as root is especially dangerous because package-manager invocation can commonly be adapted to execute arbitrary commands or package installation hooks with root p ...[truncated 1100 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove remote account creation and sudo-policy changes from the key-transfer example. - Require separate, explicit, human-approved provisioning steps for every remote mutation. - Never grant `NOPASSWD` access to a general-purpose package manager. - Use a pre-created, least-privileged service account with narrowly scoped authorization. - If sudo is genuinely required, permit only a purpose-built, validated command with fixed arguments. - Validate usernames and hostnames against strict allowlists before using them in remote commands. - Use `sudo visudo -cf` to validate any proposed sudo policy before installation. - Prefer constrained `authorized_keys` entries using options such as `from=`, `command=`, `no-port-forwarding`, `no-agent-forwarding`, `no-X11-forwarding`, and `no-pty`. - Require a confirmation step identifying the target host, account, key fingerprint, and exact access policy. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: examples/api-token-sharing.md:43
• Finding: Predictable Shared Temporary Files Expose Secrets to Local Attacks<![CDATA[ ## Vulnerability Details **File Location**: `examples/api-token-sharing.md:43-86` **Additional Locations**: `SKILL.md:190-200, 225-231, 316-334`; `README.md:92-102, 140-142, 259-264, 288-290`; `examples/agent-to-human.md:43-78, 103-133, 150-180, 201-243, 257-334, 352-398`; `examples/ssh-key-sharing.md:17-74, 109-143, 167-214` **Vulnerability Type**: Predictable temporary paths and insecure secret staging **Risk Level**: High ### Vulnerable Code ```bash #!/bin/bash # receive-and-store-token.sh CODE="$1" # Passed from human: 3-noble-cactus TEMP_TOKEN="/tmp/api-token" TOKEN_FILE="$HOME/.config/myapp/token" # 1. Receive token echo "[INFO] Receiving API token..." wormhole receive <<< "$CODE" > "$TEMP_TOKEN" # Check if token was received if [ ! -s "$TEMP_TOKEN" ]; then echo "[ERROR] Failed to receive token" exit 1 fi # 2. Store securely (choose your method) # Option A: Store in password manager (pass) if command -v pass &> /dev/null; then echo "[INFO] Storing in password manager..." pass insert -m api/production-token < "$TEMP_TOKEN" echo "[SUCCESS] Token stored in password manager" # Option B: Store in keyring (secret-tool) elif command -v secret-tool &> /dev/null; then echo "[INFO] Storing in keyring..." SECRET=$(cat "$TEMP_TOKEN") secret-tool store --label='API Token' service myapp secret api-token <<< "$SECRET" echo "[SUCCESS] Token stored in keyring" # Option C: Store in secure file (chmod 600) else echo "[INFO] Storing in secure file..." mkdir -p "$(dirname "$TOKEN_FILE")" cp "$TEMP_TOKEN" "$TOKEN_FILE" chmod 600 "$TOKEN_FILE" echo "[SUCCESS] Token stored in: $TOKEN_FILE" fi # 3. Cleanup rm -f "$TEMP_TOKEN" echo "[INFO] Cleanup complete." ``` ### Technical Analysis The examples repeatedly store passwords, tokens, and private keys under fixed names such as `/tmp/api-token`, `/tmp/deploy-key`, `/tmp/password`, and `/tmp/credentials`. They do not establish `umask 077`, do not create te ...[truncated 1424 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Set `umask 077` before creating any secret-bearing file. - Replace fixed `/tmp` names with an atomically created directory: ```bash umask 077 TEMP_DIR="$(mktemp -d)" TEMP_TOKEN="$TEMP_DIR/token" cleanup() { rm -rf -- "$TEMP_DIR" } trap cleanup EXIT HUP INT TERM ``` - Quote every path and use `--` before path operands where supported. - Refuse to operate if a target path already exists unexpectedly. - Prefer streaming directly between Wormhole and a password manager rather than staging plaintext on disk. - Create destination directories with mode `0700` and destination files atomically with mode `0600`. - Register cleanup before receiving or generating the secret so errors and signals cannot bypass it. - Avoid loading secrets into unnecessary shell variables, which may increase exposure through debugging or process inspection. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:237
• Finding: Documentation Encourages Transfer of Existing SSH Identities and Entire SSH Directories<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:237-247` **Additional Locations**: `README.md:182-185`; `docs/advanced-usage.md:608-612` **Vulnerability Type**: Excessive disclosure of authentication material **Risk Level**: High ### Vulnerable Code ```bash #### Sending Secrets ```bash # Send text/secret wormhole send --text "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5..." # Send file wormhole send ~/.ssh/id_rsa # Send directory wormhole send ~/.ssh/ ``` ``` ### Technical Analysis Sending a newly generated, purpose-specific key can be consistent with the Skill's stated SSH-key distribution function. Sending the user's existing default private key or the entire `~/.ssh` directory is not least-privileged. An SSH directory may contain multiple private keys, certificates, host aliases, proxy commands, known-host information, control-socket configuration, and other authentication-related data. An existing `id_rsa` may authorize access to many unrelated systems. The recipient therefore obtains broader access than necessary for the requested transfer. Magic Wormhole protects the transfer channel but does not make excessive disclosure safe. A recipient who legitimately receives one transfer can still misuse every credential included in it. ### Attack Path 1. An attacker requests SSH access or asks the Agent to follow the documented key-sharing command. 2. The Agent selects `~/.ssh/id_rsa` or the whole `~/.ssh` directory rather than generating a dedicated key. 3. Wormhole securely transfers the selected material to the recipient. 4. The recipient extracts unrelated private keys and configuration. 5. The recipient attempts authentication against hosts identified in configuration, history, or other available context. 6. Every service trusting the disclosed keys is potentially compromised. ### Impact Assessment The recipient may obtain access to multiple unrelated servers and accounts rather than a single intended target. The scope is determined by where ...[truncated 142 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove examples that send `~/.ssh/id_rsa` or the entire `~/.ssh` directory. - Generate a new Ed25519 key pair for each recipient, environment, and purpose. - Require explicit confirmation of the exact file, public-key fingerprint, recipient, and target system. - Reject directory transfers involving `.ssh` unless the user explicitly overrides a high-risk warning. - Never transfer unrelated private keys, SSH agent sockets, configuration files, or certificates. - Apply server-side key restrictions and short validity periods where supported. - Document revocation and rotation procedures for every distributed key. - Prefer recipient-generated keys when possible so the private key never leaves the recipient's system. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: examples/api-token-sharing.md:227
• Finding: Token Rotation Logs the Old Token and Retains Credentials in Predictable Files<![CDATA[ ## Vulnerability Details **File Location**: `examples/api-token-sharing.md:227-281` **Vulnerability Type**: Plaintext credential disclosure and delayed insecure cleanup **Risk Level**: High ### Vulnerable Code ```bash #!/bin/bash # rotate-api-token.sh SERVICE="myapp" OLD_TOKEN_FILE="/tmp/old-token" NEW_TOKEN_FILE="/tmp/new-token" # 1. Generate new token echo "[INFO] Generating new token..." NEW_TOKEN=$(openssl rand -hex 32) echo "$NEW_TOKEN" > "$NEW_TOKEN_FILE" # 2. Save old token for reference (temporary) if [ -f "$HOME/.config/$SERVICE/token" ]; then cp "$HOME/.config/$SERVICE/token" "$OLD_TOKEN_FILE" fi # 3. Send new token via wormhole echo "[INFO] Sending new token..." CODE=$(wormhole send --text "$(cat $NEW_TOKEN_FILE)" 2>&1 | grep "Wormhole code is:" | cut -d' ' -f4) # 4. Update local storage echo "[INFO] Updating local storage..." mkdir -p "$HOME/.config/$SERVICE" cp "$NEW_TOKEN_FILE" "$HOME/.config/$SERVICE/token" chmod 600 "$HOME/.config/$SERVICE/token" # 5. Report echo "" echo "=========================================" echo "Token Rotation Complete!" echo "=========================================" echo "" echo "NEW TOKEN:" echo " Receive with: wormhole receive" echo " Code: $CODE" echo "" echo "OLD TOKEN (for reference):" if [ -f "$OLD_TOKEN_FILE" ]; then echo " $(cat $OLD_TOKEN_FILE)" else echo " (no previous token found)" fi echo "" echo "Next steps:" echo " 1. Receive new token with wormhole" echo " 2. Update your application/configuration" echo " 3. Verify it works" echo " 4. Old token will be invalid after verification" echo "" # 6. Cleanup (cleanup old token after 5 minutes) ( sleep 300 rm -f "$OLD_TOKEN_FILE" "$NEW_TOKEN_FILE" echo "[INFO] Cleanup: Temporary token files removed" ) & echo "[SUCCESS] Token rotated successfully." ``` ### Technical Analysis The workflow copies both old and new credentials into predictable files under `/tmp`. It then explicitly prints the old token to standard o ...[truncated 1225 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Never print old or new token values. - Remove the “old token for reference” output entirely. - Use the service provider's native rotation procedure: create a new token, validate it, switch consumers, and revoke the old token. - Use `mktemp` with `umask 077` if temporary storage is unavoidable. - Install an EXIT/signal trap before any secret file is created. - Perform cleanup synchronously and verify deletion rather than relying on a detached `sleep` process. - Store rollback metadata such as token identifiers or fingerprints, not plaintext token values. - Ensure the permanent token file is created atomically with mode `0600` inside a directory with mode `0700`. - Redact command output at the Agent/tool boundary as defense in depth. ]]>

T08 · Insecure Dependencies

Warning

• Location: install.sh:54
• Finding: Unpinned Third-Party Package Installation Creates a Mutable Supply-Chain Boundary<![CDATA[ ## Vulnerability Details **File Location**: `install.sh:54-97` **Additional Locations**: `install.sh:123-127`; `SKILL.md:134, 159, 504, 513`; `docs/advanced-usage.md:220` **Vulnerability Type**: Unpinned dependency installation and unrestricted upgrades **Risk Level**: Medium ### Vulnerable Code ```bash # Install using detected package manager install_wormhole() { local pkg_manager=$1 print_status "Installing magic-wormhole using $pkg_manager..." case $pkg_manager in apt) sudo apt update sudo apt install -y magic-wormhole ;; dnf) sudo dnf install -y magic-wormhole ;; zypper) sudo zypper install -y python-magic-wormhole ;; brew) brew install magic-wormhole ;; pip) # Use pip3 if available, otherwise pip if command -v pip3 &> /dev/null; then pip3 install --user magic-wormhole else pip install --user magic-wormhole fi # Add ~/.local/bin to PATH if not already present if [[ ":$PATH:" != *":$HOME/.local/bin:"* ]]; then print_status "Adding ~/.local/bin to PATH..." echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc export PATH="$HOME/.local/bin:$PATH" fi ;; *) print_error "Unknown package manager. Attempting pip installation..." if command -v pip3 &> /dev/null; then pip3 install --user magic-wormhole elif command -v pip &> /dev/null; then pip install --user magic-wormhole else print_error "pip not found. Please install Python and pip first." print_error "Visit: https://pip.pypa.io/en/stable/installation/" exit 1 fi ;; esac } ``` The documentation also rec ...[truncated 1529 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin reviewed package versions explicitly. - Maintain a hash-locked requirements file and install with hash verification: ```bash python3 -m pip install --require-hashes -r requirements.lock ``` - Install Python dependencies into a dedicated virtual environment rather than the user's global environment. - Record and verify the expected package source. - Avoid unrestricted `--upgrade` commands for transitive dependencies. - Use a dependency update process that includes review, testing, vulnerability scanning, and lockfile regeneration. - Prefer signed and trusted operating-system repositories when their package versions meet security requirements. - Display the exact version and source to the user before installation. - Avoid automatically modifying shell startup files; instead, provide an explicit command the user may approve. ]]>

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
• YARA Signatures: Malware Match, Webshell Match, Cryptominer Match
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (164)

Ssd 3

High

• Confidence: 99% confidence
• Finding: This section is a direct natural-language request for the human to disclose a sensitive authentication token to the agent. Because API tokens can grant publication authority and possibly account access, convincing users to hand them to an agent materially increases the risk of unauthorized publishing, account misuse, and credential leakage through logs or prompt history.

Ssd 3

High

• Confidence: 99% confidence
• Finding: The 'Immediate Action Required' instructions explicitly tell the user to copy a one-time token and provide it to the agent, strongly encouraging disclosure of active credentials. In the context of a skill publication workflow, that token likely carries real write permissions, so the pattern is especially dangerous and not merely theoretical.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

echo "Code: $CODE"

# 4. Cleanup
rm -f /tmp/key /tmp/key.pub
```

**Human receives:**

• Confidence: 85% 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).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

echo "Code: $CODE"

# 4. Cleanup
rm -f /tmp/key /tmp/key.pub
```

**Human receives:**

• Confidence: 85% 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).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

# Agent: Receive and store
wormhole receive <<< "3-noble-cactus" > /tmp/token
pass insert -m api/production-key < /tmp/token
rm /tmp/token
```

### Password Rotation

• Confidence: 85% 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).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

# Agent: Receive and store
wormhole receive <<< "3-noble-cactus" > /tmp/token
pass insert -m api/production-key < /tmp/token
rm /tmp/token
```

### Password Rotation

• Confidence: 85% 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).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

PUBLIC_KEY=$(cat /tmp/prod-key.pub)
echo "SSH key generated! Private key code: $CODE"
echo "Public key: $PUBLIC_KEY"
rm -f /tmp/prod-key /tmp/prod-key.pub
```

**Agent response**: "SSH key generated! Private key code: 7-blue-rabbit. Public key: ssh-ed25519 AAAA..."

• Confidence: 85% 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).

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 93% confidence
• Finding: The skill is presented as a secure secret-sharing capability, but the documentation also instructs users to install software via package managers and pip, modify shell startup files, and use privileged commands. That behavior is not inherently malicious, but it expands the operational impact beyond simple secret transfer and can surprise agents or operators that rely on the declared metadata and permissions model.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

pass insert -m api/production-key < /tmp/secret

# 3. Cleanup
rm -f /tmp/secret
echo "Secret stored securely."
```

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

wormhole send --text "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5..."

# Send file
wormhole send ~/.ssh/id_rsa

# Send directory
wormhole send ~/.ssh/

• Confidence: 95% confidence
• Finding: The documentation explicitly shows transferring ~/.ssh/id_rsa and even the entire ~/.ssh directory. Encouraging movement of private SSH keys greatly increases the risk of credential theft, accidental over-sharing of unrelated keys/configs, and long-term compromise if recipients or logs are not tightly controlled.

Credential Access

High

• Category: Privilege Escalation

Content

```bash
# Use longer codes for production secrets
wormhole send --code-length 4 production-credentials.json
```

### Verification Mode

• Confidence: 88% confidence
• Finding: Using a concrete example like production-credentials.json encourages transfer of live production credentials and does so without emphasizing recipient verification, endpoint security, short-lived secrets, or post-transfer rotation. In a secret-sharing tool, this context makes the omission more dangerous because users are likely to copy these commands into real operational workflows.

Credential Access

High

• Category: Privilege Escalation

Content

```bash
# Encrypt and send via wormhole
gpg --encrypt --recipient [e-mail] secret.txt
wormhole send secret.txt.gpg

# Receive and decrypt

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

Credential Access

High

• Category: Privilege Escalation

Content

```bash
# Encrypt and send via wormhole
gpg --encrypt --recipient [e-mail] secret.txt
wormhole send secret.txt.gpg

# Receive and decrypt

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

Credential Access

High

• Category: Privilege Escalation

Content

```bash
# Encrypt and send via wormhole
gpg --encrypt --recipient [e-mail] secret.txt
wormhole send secret.txt.gpg

# Receive and decrypt

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

Missing User Warnings

High

• Confidence: 99% confidence
• Finding: The documentation explicitly shows transferring an SSH private key and loading a received key into ssh-agent with no warning about the extreme sensitivity of private keys, passphrase requirements, or host/recipient verification. Disclosure of a private key can immediately enable unauthorized access, lateral movement, and long-term persistence across infrastructure.

Credential Access

High

• Category: Privilege Escalation

Content

```bash
# Send SSH private key
wormhole send ~/.ssh/id_rsa

# Add received key to ssh-agent
wormhole receive | ssh-add -

• Confidence: 99% confidence
• Finding: The example instructs users to send an SSH private key file directly, which is highly sensitive credential material. In this skill context, the example normalizes movement of root-equivalent or infrastructure credentials and can lead to immediate compromise if transferred to the wrong recipient, intercepted through endpoint compromise, or mishandled after receipt.

Credential Access

High

• Category: Privilege Escalation

Content

echo ""
echo "  2. Save database password to password manager"
echo ""
echo "  3. Save API token to password manager or .env file"
echo ""
echo "  4. Add public key to server's authorized_keys:"
echo "     echo '$PUBLIC_KEY' >> ~/.ssh/authorized_keys"

• Confidence: 91% confidence
• Finding: The documentation suggests storing API tokens in a .env file, which encourages plaintext credential storage in a location commonly read by tools, accidentally committed, backed up, or exposed through misconfiguration. In the context of a secret-handling skill, this weakens the protection gained from secure transfer.

YARA rule 'backdoor_persistence': Backdoor persistence with malicious payloads (shell commands, SSH key injection, hidden root users) [malware]

High

• Category: YARA Match

Content

API TOKEN:"
echo "  Receive: wormhole receive"
echo "  Code: $API_CODE"
echo ""
echo "Instructions:"
echo "  1. Save SSH private key: ~/.ssh/$DEPLOY_USER-key"
echo "     chmod 600 ~/.ssh/$DEPLOY_USER-key"
echo ""
echo "  2. Save database password to password manager"
echo ""
echo "  3. Save API token to password manager or .env file"
echo ""
echo "  4. Add public key to server's authorized_keys:"
echo "     echo '$PUBLIC_KEY' >> ~/.ssh/authorized_keys"
echo ""
echo "  5. Test SSH access:"
echo "     ssh -i ~/.ssh/$DEPLOY_USER-key $DEPLOY_USER@$SERVER"
echo ""

# 9. Cleanup
rm -rf "$TEMP_DIR"
echo "[SUCCESS] Deployment workflow complete. All temporary files cleaned up."
```

---

## Error Handling Patterns

### Robust Script with Error Handling

```bash
#!/bin/bash
# robust-secret-generation.sh

set -e  # Exit on error

# Configuration
SECRET_TYPE="${1:-password}"  # Default: password
TEMP_SECRET="/tmp/generated-secret"

# Function to cleanup on exit
cleanup() {
    if [ -f "$TEMP_SECRE

• Confidence: 75% confidence
• Finding: YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).

Credential Access

High

• Category: Privilege Escalation

Content

chmod 600 ~/.config/myapp/token

# Option D: Environment file
echo "TOKEN=your-secret-here" >> ~/.env
chmod 600 ~/.env
```

• Confidence: 94% confidence
• Finding: The explicit example of echoing a secret into ~/.env normalizes storing credentials in plaintext and may also leave traces in shell history depending on how adapted by users. This creates a local credential exposure risk inconsistent with the secure-sharing goals of the skill.

Credential Access

High

• Category: Privilege Escalation

Content

# Option D: Environment file
echo "TOKEN=your-secret-here" >> ~/.env
chmod 600 ~/.env
```

### Verifying Secrets

• Confidence: 90% confidence
• Finding: The surrounding guidance reinforces use of ~/.env as a destination for secrets, which can persist credentials in plaintext despite restrictive permissions. Attackers with local access, backups, or accidental sync/commit pathways may obtain the token.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

```bash
# Generate password and send
openssl rand -base64 24 | tee /tmp/p | wormhole send --text "$(cat /tmp/p)" 2>&1 | grep "Wormhole code is:" | cut -d' ' -f4 && rm /tmp/p

# Generate token and send
openssl rand -hex 32 | tee /tmp/t | wormhole send --text "$(cat /tmp/t)" 2>&1 | grep "Wormhole code is:" | cut -d' ' -f4 && rm /tmp/t

• Confidence: 89% confidence
• Finding: The one-liner writes a generated secret to a predictable file in /tmp and uses tee, increasing the chance of exposure through race conditions, symlink attacks, permissive temp handling, or leftover artifacts if the chain breaks. Quick-reference snippets are likely to be copied verbatim, making this pattern more dangerous than the longer scripts.

Chaining Abuse

High

• Category: Tool Misuse

Content

```bash
# Generate password and send
openssl rand -base64 24 | tee /tmp/p | wormhole send --text "$(cat /tmp/p)" 2>&1 | grep "Wormhole code is:" | cut -d' ' -f4 && rm /tmp/p

# Generate token and send
openssl rand -hex 32 | tee /tmp/t | wormhole send --text "$(cat /tmp/t)" 2>&1 | grep "Wormhole code is:" | cut -d' ' -f4 && rm /tmp/t

• Confidence: 84% confidence
• Finding: The pipeline/chain style processes secret material through multiple shell stages and performs cleanup only on full success, so errors can leave the temporary secret file behind. This is risky in documentation because users may copy the compact form without understanding the failure modes.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

openssl rand -base64 24 | tee /tmp/p | wormhole send --text "$(cat /tmp/p)" 2>&1 | grep "Wormhole code is:" | cut -d' ' -f4 && rm /tmp/p

# Generate token and send
openssl rand -hex 32 | tee /tmp/t | wormhole send --text "$(cat /tmp/t)" 2>&1 | grep "Wormhole code is:" | cut -d' ' -f4 && rm /tmp/t

# Generate SSH key and send
ssh-keygen -t ed25519 -f /tmp/k -N "" && CODE=$(wormhole send --text "$(cat /tmp/k)" 2>&1 | grep "Wormhole code is:" | cut -d' ' -f4) && echo "Code: $CODE" && echo "Pub: $(cat /tmp/k.pub)" && rm -f /tmp/k /tmp/k.pub

• Confidence: 89% confidence
• Finding: This token one-liner uses a predictable temporary filename in /tmp and lacks robust error handling or guaranteed cleanup. On multi-user systems or failure conditions, secrets may remain accessible or be redirected via filesystem tricks.

Chaining Abuse

High

• Category: Tool Misuse

Content

openssl rand -base64 24 | tee /tmp/p | wormhole send --text "$(cat /tmp/p)" 2>&1 | grep "Wormhole code is:" | cut -d' ' -f4 && rm /tmp/p

# Generate token and send
openssl rand -hex 32 | tee /tmp/t | wormhole send --text "$(cat /tmp/t)" 2>&1 | grep "Wormhole code is:" | cut -d' ' -f4 && rm /tmp/t

# Generate SSH key and send
ssh-keygen -t ed25519 -f /tmp/k -N "" && CODE=$(wormhole send --text "$(cat /tmp/k)" 2>&1 | grep "Wormhole code is:" | cut -d' ' -f4) && echo "Code: $CODE" && echo "Pub: $(cat /tmp/k.pub)" && rm -f /tmp/k /tmp/k.pub

• Confidence: 84% confidence
• Finding: This chained token-transfer one-liner lacks robust failure handling and can leave secret artifacts in predictable temporary storage. In secret management documentation, encouraging compact shell chains increases accidental leakage risk.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

openssl rand -hex 32 | tee /tmp/t | wormhole send --text "$(cat /tmp/t)" 2>&1 | grep "Wormhole code is:" | cut -d' ' -f4 && rm /tmp/t

# Generate SSH key and send
ssh-keygen -t ed25519 -f /tmp/k -N "" && CODE=$(wormhole send --text "$(cat /tmp/k)" 2>&1 | grep "Wormhole code is:" | cut -d' ' -f4) && echo "Code: $CODE" && echo "Pub: $(cat /tmp/k.pub)" && rm -f /tmp/k /tmp/k.pub
```

---

• Confidence: 90% confidence
• Finding: The SSH key one-liner creates highly sensitive key material in predictable /tmp paths and chains generation, transmission, printing, and deletion in a fragile sequence. If any step fails or the temporary path is interfered with, the private key may be exposed or left behind.