VPN Tunnel

• Outcome: Review
• Latest audit: Sep 16, 2026 · 9:49 AM UTC
• Version: 1.0.0

Overview

This VPN skill has a coherent purpose, but it embeds reusable local sudo and remote SSH passwords and disables SSH host verification while changing VPN/proxy state.

Review before installing. Do not use this package as published unless the embedded local and SSH passwords have been removed and rotated, SSH host-key verification is restored, and privileged WireGuard actions are handled through an explicit least-privilege mechanism controlled by the user.

A.I.G

Vulnerability Patterns

• 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
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (4)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/vpn-up.sh:14

Finding

Hardcoded Local Sudo Password Exposes a Privileged Credential

Content

View full analysis

Vulnerability Details

File Location: scripts/vpn-up.sh:14,20; scripts/vpn-down.sh:18; scripts/vpn-status.sh:8
Vulnerability Type: Hardcoded privileged credential
Risk Level: High

Vulnerable Code

scripts/vpn-up.sh:14

bash

echo "crscd" | sudo -S wg-quick up wg0 2>/dev/null || {
    echo "  WireGuard already up or failed to start"
}

scripts/vpn-up.sh:20

bash

if echo "crscd" | sudo -S wg show 2>/dev/null | grep -q "handshake"; then
    echo "  Handshake established ✓"
    break
fi

scripts/vpn-down.sh:18

bash

echo "crscd" | sudo -S wg-quick down wg0 2>/dev/null || {
    echo "  WireGuard already down"
}

scripts/vpn-status.sh:8

bash

echo "crscd" | sudo -S wg show 2>/dev/null || echo "  Not connected"

Technical Analysis

A local account password is embedded directly in three distributable shell scripts and supplied to sudo through standard input. Anyone able to read the Skill package can recover the plaintext value.

Although the scripts invoke only WireGuard commands, the exposed password is not technically restricted to those commands. If it is the valid password of a local account with broader sudo privileges, a user or process that gains access to that account can attempt to invoke any command allowed by its sudo policy.

Copies of the package, source-control history, backups, logs, or shared archives may retain the credential even after the current files are changed.

Attack Path

1. An attacker obtains read access to the Skill package or a historical copy.
2. The attacker reads any affected script and recovers the embedded password.
3. The attacker identifies or gains a shell under the corresponding local account.
4. The attacker supplies the recovered password to sudo.
5. The attacker executes commands permitted by that account's sudo policy, potentially including commands as root.

Impact Assessment

...[truncated 405 chars]

Remediation

View remediation

Remediation Suggestions

1. Remove the plaintext password from every script and rotate the affected local account password immediately.
2. Review source-control history, backups, distributed archives, and deployment copies for the exposed value.
3. Do not automate sudo by piping a password through standard input.
4. If unattended operation is required, create a narrowly scoped rule under /etc/sudoers.d/ that permits only the required WireGuard operations using absolute executable paths and fixed arguments.
5. Do not grant unrestricted passwordless sudo to the Skill or its executing account.
6. Prefer a dedicated service or privileged helper with a minimal, validated interface if network administration must be delegated.
7. Restrict ownership and permissions of the WireGuard configuration and any privileged helper.
8. Require interactive authorization when unattended privileged execution is not essential.

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/vpn-up.sh:7

Finding

Hardcoded Remote SSH Username and Password Permit Credential Reuse

Content

View full analysis

Vulnerability Details

File Location: scripts/vpn-up.sh:7-9,32
Vulnerability Type: Hardcoded remote-service credential
Risk Level: High

Vulnerable Code

bash

CLOUD_SSH_HOST="47.85.45.122"
CLOUD_SSH_USER="smile"
CLOUD_SSH_PASS="thXBwViKf+uSUL0LIZTZ3AeV"

bash

sshpass -p "$CLOUD_SSH_PASS" ssh -o StrictHostKeyChecking=no -o ServerAliveInterval=60 -f -N -D $SOCKS_PORT "$CLOUD_SSH_USER@$CLOUD_SSH_HOST" 2>/dev/null

Technical Analysis

The package contains the VPS address, SSH username, and plaintext SSH password. These values can be recovered by every person or process with read access to the Skill.

The credential is not bound to the intended dynamic-forwarding invocation. Unless the server independently restricts the account, an attacker can use a normal SSH client to authenticate directly and exercise all capabilities granted to the smile account.

Use of sshpass -p also places the secret in an insecure automation pattern. Depending on the operating system and sshpass implementation, process inspection and debugging facilities may create additional opportunities for local disclosure.

Attack Path

1. An attacker reads scripts/vpn-up.sh.
2. The attacker extracts the host, username, and password.
3. The attacker initiates a direct SSH connection to 47.85.45.122 as smile.
4. If the credential remains valid and network access is allowed, the attacker authenticates to the VPS.
5. The attacker uses the account for unauthorized proxying, resource consumption, access to account-readable data, or additional compromise attempts.
6. If the account has elevated permissions or access to sensitive services, the attacker expands control within the VPS accordingly.

Impact Assessment

Successful exploitation grants the attacker the same remote privileges as the exposed SSH account. The exact server-side privileges are not established by the audited files, but possible effe ...[truncated 413 chars]

Remediation

View remediation

Remediation Suggestions

1. Revoke and rotate the exposed SSH password immediately.
2. Remove the credential from the current package, source-control history, release archives, backups, and deployment copies where feasible.
3. Disable SSH password authentication for this account.
4. Provision a separate SSH key for each authorized user or deployment rather than distributing one shared credential.
5. Protect private keys with restrictive file permissions and, where operationally possible, a passphrase or managed SSH agent.
6. Restrict the server account to the minimum required forwarding capability. Consider AllowTcpForwarding, PermitOpen, ForceCommand, restricted shells, firewall rules, and source-address restrictions.
7. Prevent the forwarding account from using sudo or accessing unrelated server files and services.
8. Add server-side authentication monitoring, connection rate limits, and credential-reuse alerts.

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/vpn-up.sh:32

Finding

Disabled SSH Host-Key Verification Enables Server Impersonation

Content

View full analysis

Vulnerability Details

File Location: scripts/vpn-up.sh:32
Vulnerability Type: Missing SSH server authenticity verification
Risk Level: Medium

Vulnerable Code

bash

sshpass -p "$CLOUD_SSH_PASS" ssh -o StrictHostKeyChecking=no -o ServerAliveInterval=60 -f -N -D $SOCKS_PORT "$CLOUD_SSH_USER@$CLOUD_SSH_HOST" 2>/dev/null

Technical Analysis

StrictHostKeyChecking=no allows SSH to proceed without requiring trusted, pre-established verification of the server's host key. This weakens SSH's protection against server impersonation.

Because the same invocation performs password authentication, an attacker capable of redirecting or intercepting the SSH connection may present an attacker-controlled SSH server. If the client accepts that server and proceeds with password authentication, the attacker may capture the embedded SSH password. An attacker-controlled endpoint could also become the effective SOCKS forwarding peer, affecting the confidentiality and integrity of traffic sent through the proxy.

Attack Path

1. An attacker obtains a position capable of redirecting or intercepting traffic to the configured VPS, such as through network, routing, or local host manipulation.
2. The attacker redirects the SSH connection to an attacker-controlled SSH service.
3. The malicious service presents an untrusted host key.
4. The client does not enforce a trusted host-key match because strict checking is disabled.
5. The client attempts password authentication, potentially disclosing the remote credential to the impersonating endpoint.
6. The attacker may reuse the captured password against the legitimate VPS or provide a malicious forwarding endpoint for proxied connections.

Impact Assessment

Exploitation can expose the remote SSH credential and undermine the authenticity of the proxy endpoint. A captured credential grants the attacker the remote account privileges described in the hardcoded-credenti ...[truncated 318 chars]

Remediation

View remediation

Remediation Suggestions

1. Replace StrictHostKeyChecking=no with StrictHostKeyChecking=yes.
2. Obtain the VPS host-key fingerprint through a trusted, independent channel before deployment.
3. Pin the verified host key in a dedicated known_hosts file controlled by the Skill operator.
4. Specify that file with UserKnownHostsFile and ensure it is not writable by untrusted users.
5. Prefer modern key-based client authentication rather than password authentication.
6. Treat any unexpected host-key change as a security event requiring manual verification.
7. Rotate the currently exposed SSH credential because the existing configuration cannot establish that it was never presented to an impersonating endpoint.

T09 · Insecure Skill Coding Practices

Note

• Location: scripts/vpn-up.sh:29

Finding

Broad Command-Line Pattern Matching Can Terminate Unrelated SSH Processes

Content

View full analysis

Vulnerability Details

File Location: scripts/vpn-up.sh:29,35; scripts/vpn-down.sh:11; scripts/vpn-status.sh:12,19
Vulnerability Type: Unsafe process identification and termination
Risk Level: Low

Vulnerable Code

scripts/vpn-up.sh:29

bash

pkill -f "ssh.*-D $SOCKS_PORT.*$CLOUD_SSH_HOST" 2>/dev/null || true

scripts/vpn-up.sh:35

bash

if pgrep -f "ssh.*-D $SOCKS_PORT" > /dev/null; then
    echo "  SOCKS5 proxy running on 127.0.0.1:$SOCKS_PORT ✓"
else
    echo "  ERROR: SOCKS5 proxy failed to start"
    exit 1
fi

scripts/vpn-down.sh:11

bash

if pkill -f "ssh.*-D $SOCKS_PORT.*$CLOUD_SSH_HOST" 2>/dev/null; then
    echo "  SOCKS5 proxy stopped ✓"
else
    echo "  No SOCKS5 proxy running"
fi

scripts/vpn-status.sh:12,19

bash

if pgrep -f "ssh.*-D $SOCKS_PORT" > /dev/null; then
    echo "  Running on 127.0.0.1:$SOCKS_PORT ✓"
else
    echo "  Not running"
fi

bash

if pgrep -f "ssh.*-D $SOCKS_PORT" > /dev/null; then
    echo "  Google: $(curl -s --max-time 8 --proxy socks5h://127.0.0.1:$SOCKS_PORT -o /dev/null -w '%{http_code}' https://www.google.com 2>/dev/null || echo FAIL)"
    echo "  GitHub: $(curl -s --max-time 8 --proxy socks5h://127.0.0.1:$SOCKS_PORT -o /dev/null -w '%{http_code}' https://github.com 2>/dev/null || echo FAIL)"
else
    echo "  Proxy not running, skip"
fi

Technical Analysis

The scripts identify the managed SSH process by applying regular expressions to complete process command lines with pgrep -f and pkill -f. A command line is not a reliable process-ownership identifier.

Another SSH dynamic-forwarding session using port 1080 and the same host could match the termination pattern. Status checks are broader and can match any process whose command line contains the expected text, including an unrelated or deliberately crafted process.

This can cause false status results, tests to r ...[truncated 1103 chars]

Remediation

View remediation

Remediation Suggestions

1. Manage the SSH instance through a dedicated SSH control socket created in a private directory.
2. Alternatively, record the spawned process ID in a securely created PID file owned by the executing user and inaccessible to other users.
3. Before signaling a recorded PID, verify that the process still exists, is owned by the expected user, and has the expected executable and arguments.
4. Use SSH control commands such as ssh -S control_socket -O check and ssh -S control_socket -O exit rather than command-line regex matching.
5. Confirm proxy readiness by checking the expected listening socket and validating the managed SSH control connection.
6. Avoid treating any process that happens to use port 1080 as belonging to this Skill.
7. Quote shell variable expansions consistently and use explicit argument separators where supported.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger

Findings (22)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

This is a strong true positive because the documented behavior understates materially risky actions: hardcoded credentials, privileged WireGuard setup via sudo, and disabled SSH host key checking. Those behaviors can expose reusable secrets, enable unauthorized remote access, permit local privilege abuse, and make man-in-the-middle attacks against the SSH proxy more feasible.

Content

No source excerpt is available for this finding.

Missing User Warnings

High

• Category: Not specified by scanner
• Confidence: 99% confidence

Finding

The script contains a hardcoded sudo password and pipes it directly into sudo to run wg-quick as root. This exposes a reusable local privilege secret to anyone who can read the file, shell history, backups, or logs, and normalizes silent privileged execution without user awareness. In the context of a VPN skill that manipulates network routing, this is especially dangerous because compromise of the password can lead to broader host-level administrative access.

Content

No source excerpt is available for this finding.

Chaining Abuse

High

• Category: Tool Misuse
• Confidence: 93% confidence

Finding

Piping data into sudo creates a chaining pattern that suppresses normal authentication boundaries and enables scripted privilege escalation. In this file, the pipe is used specifically to feed a hardcoded password into a root command, making the chain directly exploitable rather than merely suspicious. Given the VPN skill's purpose of changing routing and proxy state, this increases the operational impact of abuse or unauthorized execution.

Content

Scanner excerpt · scripts/vpn-down.sh (reported line 18)May include surrounding context.

sh

fi

echo "[2/2] Stopping WireGuard..."
echo "crscd" | sudo -S wg-quick down wg0 2>/dev/null || {
    echo "  WireGuard already down"
}

Missing User Warnings

High

• Category: Not specified by scanner
• Confidence: 99% confidence

Finding

The script contains a hardcoded sudo password and pipes it into sudo -S, which embeds privileged credentials directly in code. Any user who can read the file, shell history, process context, backups, or repository contents may recover the password and reuse it for broader privilege escalation beyond this script.

Content

No source excerpt is available for this finding.

Chaining Abuse

High

• Category: Tool Misuse
• Confidence: 93% confidence

Finding

Piping a string into sudo creates a chaining pattern that automates a privileged action and, here, directly carries a secret into a root-context command. In a VPN skill that manages tunneling infrastructure, this increases danger because the script is already associated with network control and could be modified or reused to execute other privileged commands with the same credential handling pattern.

Content

Scanner excerpt · scripts/vpn-status.sh (reported line 8)May include surrounding context.

sh

SOCKS_PORT=1080

echo "=== WireGuard ==="
echo "crscd" | sudo -S wg show 2>/dev/null || echo "  Not connected"

echo ""
echo "=== SOCKS5 Proxy ==="

Context-Inappropriate Capability

High

• Category: Not specified by scanner
• Confidence: 99% confidence

Finding

The script hardcodes both an SSH password and a sudo password, exposing reusable privileged credentials directly in code. Anyone who can read the skill or logs can recover these secrets and gain unauthorized local root-level VPN control and remote VPS access, which is far beyond a normal client-side VPN helper's minimum trust requirements.

Content

No source excerpt is available for this finding.

Chaining Abuse

High

• Category: Tool Misuse
• Confidence: 94% confidence

Finding

Piping a hardcoded string into sudo chains untrusted script execution directly into privileged command execution, creating a turnkey escalation path. In the context of an externally sourced skill, this is particularly dangerous because any later modification of the command path would automatically inherit root execution using the embedded password.

Content

Scanner excerpt · scripts/vpn-up.sh (reported line 14)May include surrounding context.

sh

# === Start WireGuard ===
echo "[1/3] Starting WireGuard..."
echo "crscd" | sudo -S wg-quick up wg0 2>/dev/null || {
    echo "  WireGuard already up or failed to start"
}

Chaining Abuse

High

• Category: Tool Misuse
• Confidence: 90% confidence

Finding

The second password pipe to sudo extends the same chaining pattern to additional commands, increasing the opportunities for abuse or accidental privilege misuse. Even though the immediate command is a status check, the pattern creates an unsafe precedent where arbitrary scripted logic can be coupled to root operations.

Content

Scanner excerpt · scripts/vpn-up.sh (reported line 21)May include surrounding context.

sh

# Wait for handshake
echo "[2/3] Waiting for handshake..."
for i in $(seq 1 10); do
    if echo "crscd" | sudo -S wg show 2>/dev/null | grep -q "handshake"; then
        echo "  Handshake established ✓"
        break
    fi

Undeclared Tool Scope

Medium

• Category: MCP Least Privilege
• Confidence: 91% confidence

Finding

The skill invokes shell scripts that bring up/down a VPN and proxy, but it declares no explicit tool scope or permissions. That omission hides the fact that the skill can execute local commands and likely perform network and system-level actions, reducing reviewability and allowing an agent to use powerful capabilities without clear user or platform visibility.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

The trigger phrases include broad requests like "use VPN," "change IP," or "access international sites," which can cause the skill to activate in situations beyond the intended blocked-site use case. In this context, broad matching is more dangerous because the skill appears to perform privileged local networking changes and route traffic through a third-party VPS, increasing the chance of unnecessary or unintended tunnel use.

Content

No source excerpt is available for this finding.

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 95% confidence

Finding

Using sudo -S causes sudo to read the password from standard input, which facilitates non-interactive privilege escalation and is unsafe when paired with a hardcoded secret. This pattern can leak credentials and allows anyone able to execute or inspect the script to trigger privileged actions on the host. Because the skill manages VPN/networking state, misuse could disrupt connectivity or be chained into broader host compromise.

Content

Scanner excerpt · scripts/vpn-down.sh (reported line 18)May include surrounding context.

sh

fi

echo "[2/2] Stopping WireGuard..."
echo "crscd" | sudo -S wg-quick down wg0 2>/dev/null || {
    echo "  WireGuard already down"
}

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 95% confidence

Finding

Using sudo -S causes sudo to read the password from standard input, which facilitates non-interactive privilege escalation and is unsafe when paired with a hardcoded secret. This pattern can leak credentials and allows anyone able to execute or inspect the script to trigger privileged actions on the host. Because the skill manages VPN/networking state, misuse could disrupt connectivity or be chained into broader host compromise.

Content

Scanner excerpt · scripts/vpn-down.sh (reported line 18)May include surrounding context.

sh

fi

echo "[2/2] Stopping WireGuard..."
echo "crscd" | sudo -S wg-quick down wg0 2>/dev/null || {
    echo "  WireGuard already down"
}

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 97% confidence

Finding

sudo -S instructs sudo to read the password from standard input, enabling scripted credential injection. In this file it is paired with a hardcoded password, making privilege escalation automated and exposing secrets in source code and potentially in execution artifacts.

Content

Scanner excerpt · scripts/vpn-status.sh (reported line 8)May include surrounding context.

sh

SOCKS_PORT=1080

echo "=== WireGuard ==="
echo "crscd" | sudo -S wg show 2>/dev/null || echo "  Not connected"

echo ""
echo "=== SOCKS5 Proxy ==="

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 97% confidence

Finding

sudo -S instructs sudo to read the password from standard input, enabling scripted credential injection. In this file it is paired with a hardcoded password, making privilege escalation automated and exposing secrets in source code and potentially in execution artifacts.

Content

Scanner excerpt · scripts/vpn-status.sh (reported line 8)May include surrounding context.

sh

SOCKS_PORT=1080

echo "=== WireGuard ==="
echo "crscd" | sudo -S wg show 2>/dev/null || echo "  Not connected"

echo ""
echo "=== SOCKS5 Proxy ==="

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 89% confidence

Finding

The script performs undisclosed outbound requests to Google and GitHub as part of its status check. While this is less severe than credential exposure, it can leak operational metadata such as that the host is using a VPN/proxy, trigger network monitoring, or violate user expectations in restricted environments.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 91% confidence

Finding

The script silently handles sensitive remote-access and privilege-escalation credentials without warning the user that running it will use embedded secrets and establish access to a fixed external host. In this context, the lack of disclosure increases the chance of unsafe execution and unnoticed credential exposure, especially because the skill is effectively a remote-access bootstrapper.

Content

No source excerpt is available for this finding.

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 96% confidence

Finding

Using sudo -S explicitly reads the sudo password from standard input, which in this script is a hardcoded secret. This is a strong indicator of insecure privilege-escalation automation because the credential is stored in plaintext and can be recovered from the file or surrounding execution environment.

Content

Scanner excerpt · scripts/vpn-up.sh (reported line 14)May include surrounding context.

sh

# === Start WireGuard ===
echo "[1/3] Starting WireGuard..."
echo "crscd" | sudo -S wg-quick up wg0 2>/dev/null || {
    echo "  WireGuard already up or failed to start"
}

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 96% confidence

Finding

Using sudo -S explicitly reads the sudo password from standard input, which in this script is a hardcoded secret. This is a strong indicator of insecure privilege-escalation automation because the credential is stored in plaintext and can be recovered from the file or surrounding execution environment.

Content

Scanner excerpt · scripts/vpn-up.sh (reported line 14)May include surrounding context.

sh

# === Start WireGuard ===
echo "[1/3] Starting WireGuard..."
echo "crscd" | sudo -S wg-quick up wg0 2>/dev/null || {
    echo "  WireGuard already up or failed to start"
}

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 92% confidence

Finding

The second sudo -S usage repeats insecure plaintext-password privilege escalation for a diagnostic command. Reuse of the same embedded sudo secret increases the chance of disclosure and demonstrates that the script's operation depends on insecure root automation rather than safer privilege separation.

Content

Scanner excerpt · scripts/vpn-up.sh (reported line 21)May include surrounding context.

sh

# Wait for handshake
echo "[2/3] Waiting for handshake..."
for i in $(seq 1 10); do
    if echo "crscd" | sudo -S wg show 2>/dev/null | grep -q "handshake"; then
        echo "  Handshake established ✓"
        break
    fi

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 92% confidence

Finding

The second sudo -S usage repeats insecure plaintext-password privilege escalation for a diagnostic command. Reuse of the same embedded sudo secret increases the chance of disclosure and demonstrates that the script's operation depends on insecure root automation rather than safer privilege separation.

Content

Scanner excerpt · scripts/vpn-up.sh (reported line 21)May include surrounding context.

sh

# Wait for handshake
echo "[2/3] Waiting for handshake..."
for i in $(seq 1 10); do
    if echo "crscd" | sudo -S wg show 2>/dev/null | grep -q "handshake"; then
        echo "  Handshake established ✓"
        break
    fi

Context-Inappropriate Capability

Medium

• Category: Not specified by scanner
• Confidence: 98% confidence

Finding

Disabling StrictHostKeyChecking allows the script to connect to any host claiming to be the VPS without verifying its identity. This enables man-in-the-middle interception of the SSH session, credential theft, and proxy hijacking, which is especially dangerous because the script is meant to carry user traffic to external services.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 94% confidence

Finding

The script suppresses SSH identity verification without clearly informing the user that it is accepting an unverified remote endpoint. That omission makes a risky security downgrade easier to overlook and compounds the danger of routing user traffic through an attacker-controlled host if spoofing occurs.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.