Sshtunnel

• Outcome: Review
• Latest audit: Sep 16, 2026 · 9:23 AM UTC
• Version: 4.7.5

Overview

This skill is not clearly malicious, but it publishes SSH access to the internet and includes unsafe installation and connection examples that users should review carefully.

Only install this if you intentionally want to expose an SSH server through aitun. Prefer a pinned, verified package installation over the one-line scripts, avoid running installers as root, use key-only SSH with password login disabled, use a least-privilege account, rotate any token placed on a command line, and stop the tunnel when finished.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• 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 (4)

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:53
• Finding: Unverified Remote Installation Scripts Are Executed Directly<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:53`, `SKILL.md:58`, and `SKILL.md:334` **Vulnerability Type**: Remote payload retrieval followed by immediate shell execution **Risk Level**: Critical ### Complete Code Snippet ```bash curl -fsSL https://aitun.cc/install.sh | bash ``` ```powershell irm https://aitun.cc/install.ps1 | iex ``` The same installation methods are repeated in the CLI reference: ```text The `aitun` command (installed via `pip install aitun`, or alternatively `curl -fsSL https://aitun.cc/install.sh | bash` / `irm https://aitun.cc/install.ps1 | iex` on Windows) accepts these flags: ``` ### Technical Analysis These commands retrieve mutable content from an external server and execute it immediately in Bash or PowerShell. The instructions do not pin an installer version, verify a cryptographic signature or digest, preserve the script for inspection, or otherwise establish that the downloaded content matches the version reviewed during this audit. HTTPS protects the transport under ordinary conditions but does not make the remotely hosted script immutable or trustworthy. Compromise of the hosting account, domain, certificate infrastructure, web server, or release process would allow the effective installation payload to change without any modification to this Skill. This installation mechanism is not the minimum privilege or minimum-risk method necessary to provide SSH tunneling. A verified, versioned package or artifact could provide the declared functionality without executing mutable server responses directly. ### Attack Path 1. An attacker compromises `aitun.cc`, its hosting environment, DNS/TLS infrastructure, or the installer publication process. 2. The attacker replaces `install.sh` or `install.ps1` with a malicious payload. 3. A user or AI agent follows the Skill's installation instructions. 4. `curl` or `irm` downloads the attacker-controlled response. 5. Bash or PowerShell executes that response immediately ...[truncated 640 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove all `curl | bash` and `irm | iex` installation instructions. - Publish immutable, versioned installation artifacts. - Require users to download the artifact without executing it, verify a publisher signature or pinned SHA-256 digest, and only then run it as a separate step. - Document the expected artifact filename, version, digest, signing identity, and official distribution location. - Prefer an audited package-manager installation with an exact version and integrity hashes. - Explicitly advise users not to execute the installer with elevated privileges unless a documented operation strictly requires them. ]]>

T08 · Insecure Dependencies

Error

• Location: SKILL.md:16
• Finding: Unpinned Third-Party Package Installation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:16-21`, `SKILL.md:48`, and `SKILL.md:334` **Vulnerability Type**: Unpinned dependency installation from a mutable package source **Risk Level**: High ### Complete Code Snippet ```yaml install: - kind: pip package: aitun bins: [aitun] - kind: uv package: aitun bins: [aitun] ``` ```bash pip install aitun ``` The unpinned command is also repeated in the CLI reference: ```text The `aitun` command (installed via `pip install aitun`, or alternatively `curl -fsSL https://aitun.cc/install.sh | bash` / `irm https://aitun.cc/install.ps1 | iex` on Windows) accepts these flags: ``` ### Technical Analysis Neither the metadata nor the command pins `aitun` to a reviewed version or verifies package hashes. Consequently, installation resolves whichever release is selected by the package index at installation time. The installed code can therefore differ from the dependency version that existed when this Skill was reviewed. Python packages and their transitive dependencies can run code during installation or when the installed command is invoked. A compromised publisher account, malicious future release, dependency substitution, or compromised package index could introduce arbitrary code into the installation path. ### Attack Path 1. An attacker compromises the `aitun` package publisher, a transitive dependency, or the relevant package distribution infrastructure. 2. The attacker publishes a malicious version that still satisfies the unrestricted package request. 3. A user or agent executes `pip install aitun`, or the Skill manager processes the unpinned metadata. 4. The package manager resolves and installs the malicious release. 5. Malicious package code executes during installation or when the `aitun` command is used. ### Impact Assessment The malicious dependency would execute with the permissions of the account performing installation or running `aitun`. It could read user-accessi ...[truncated 250 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin `aitun` to an exact, audited version in both the Skill metadata and installation examples. - Use a lockfile or requirements file containing cryptographic hashes. - For pip, use an installation process equivalent to `--require-hashes`. - Pin and verify all transitive dependencies where applicable. - Document the expected official package index and publisher identity. - Establish a controlled update process that reviews new releases before changing the pinned version. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:193
• Finding: Example Disables TLS Certificate Validation and Omits SSH Host-Key Verification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:193-202` and `SKILL.md:232-234` **Vulnerability Type**: Missing endpoint authentication in an SSH-over-TLS connection **Risk Level**: High ### Complete Code Snippet ```python key = paramiko.RSAKey.from_private_key_file(key_path) context = ssl.create_default_context() context.check_hostname = False context.verify_mode = ssl.CERT_NONE raw_sock = socket.create_connection((host, port), timeout=10) tls_sock = context.wrap_socket(raw_sock, server_hostname=sni) transport = paramiko.Transport(tls_sock) transport.set_keepalive(30) transport.connect(username=username, pkey=key) ``` The example then connects to a hardcoded IP address: ```python transport = create_ssh_transport( host='43.160.208.156', port=22, sni='yourname.t.aitun.cc', username='mojo', key_path='/path/to/ssh_key' ) ``` ### Technical Analysis The example explicitly sets `ssl.CERT_NONE` and disables hostname checks. Any certificate presented by the remote endpoint is therefore accepted, including a self-signed or attacker-controlled certificate. The code also constructs `paramiko.Transport` directly and calls `transport.connect` without supplying an expected SSH host key or loading trusted host keys. Thus, neither the outer TLS endpoint nor the inner SSH server is authenticated by the example. Use of a hardcoded IP address further increases reliance on explicit certificate and host-key validation. Supplying the intended SNI value affects routing but does not authenticate the peer when certificate verification is disabled. Loading the private key is relevant to the declared SSH functionality and does not itself show that the key file is modified or transmitted. The security issue is that the key is used to authenticate a session whose remote endpoint has not been verified. ### Attack Path 1. An attacker gains a network interception position, redirects traffic, compromises the hardcoded endpoint, or operates a maliciou ...[truncated 945 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not set `check_hostname` to `False` or `verify_mode` to `ssl.CERT_NONE`. - Use `ssl.create_default_context()` with certificate verification enabled. - Connect using the documented hostname and validate the certificate against that hostname. - If a private CA is required, distribute and load that CA explicitly rather than disabling verification. - Verify the inner SSH server host key against a pinned fingerprint or a trusted `known_hosts` entry. - Fail closed when either TLS certificate validation or SSH host-key verification fails. - Remove the hardcoded IP address unless it is operationally required and independently authenticated. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:102
• Finding: Tunnel Authentication Token Is Passed Through Process Arguments<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:102`, `SKILL.md:110`, `SKILL.md:286`, and `SKILL.md:295` **Vulnerability Type**: Sensitive token exposure through command-line arguments and shell history **Risk Level**: Medium ### Complete Code Snippet ```bash aitun -k YOUR_TOKEN --tcp-ports 22 & AITUN_PID=$! sleep 3 ``` ```bash aitun -k YOUR_TOKEN -p 8080 --tcp-ports 22 & AITUN_PID=$! sleep 3 ``` Additional examples use the same token mechanism: ```bash aitun -k YOUR_TOKEN --tcp-ports 22,3306 & AITUN_PID=$! sleep 3 ``` ```bash aitun -k YOUR_TOKEN --tcp-ports 2222 & ``` ### Technical Analysis The documentation instructs users to replace `YOUR_TOKEN` with an authentication token passed via the `-k` command-line argument. Real tokens entered this way may be retained in shell history, terminal logs, command auditing systems, process telemetry, or automation logs. Depending on the operating system and process isolation settings, command-line arguments may also be visible to other local users while the tunnel process is running. Starting the command in the background can extend the period during which its arguments remain observable. The token is necessary for the declared TCP tunnel function, but exposing it through process arguments is not the minimum-access method needed to supply that credential. ### Attack Path 1. A user replaces `YOUR_TOKEN` with a real tunnel credential and executes the documented command. 2. The shell records the command in history, or monitoring and process-inspection facilities capture its arguments. 3. Another local user, administrator, log reader, or attacker with access to those records retrieves the token. 4. The attacker reuses the token against the tunnel service. 5. The attacker gains whatever tunnel creation or account capabilities are associated with that credential. ### Impact Assessment Exposure may permit unauthorized use of the victim's tunnel account, creation or manipulation of externally reachabl ...[truncated 244 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Add support for reading the token from a permission-restricted credential file, operating-system credential store, or standard input. - Avoid placing secrets in command-line arguments or shell scripts. - If an environment variable is supported, document its exposure limitations and ensure it is not logged. - Redact credentials from diagnostic output and process logs. - Document token rotation and immediate revocation procedures. - Recommend a narrowly scoped token dedicated to the specific tunnel rather than a broadly privileged account credential. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (13)

External Script Fetching

High

• Category: Supply Chain

Content

Or install via one-line script (Linux/macOS):
```bash
curl -fsSL https://aitun.cc/install.sh | bash
```

Windows (PowerShell):

• Confidence: 98% confidence
• Finding: `curl -fsSL https://aitun.cc/install.sh | bash` fetches and executes remote code in a single step with no integrity verification, review, or pinning. If the server, CDN, DNS, TLS trust chain, or upstream script is compromised, users can execute attacker-controlled code immediately on their machine.

Chaining Abuse

High

• Category: Tool Misuse

Content

Or install via one-line script (Linux/macOS):
```bash
curl -fsSL https://aitun.cc/install.sh | bash
```

Windows (PowerShell):

• Confidence: 98% confidence
• Finding: The `| bash` construct directly chains untrusted network content into shell execution, eliminating any opportunity for inspection or validation. This materially increases the blast radius of a compromise because a single malicious response results in arbitrary command execution.

Credential Access

High

• Category: Privilege Escalation

Content

ssh [e-mail]

# With SSH key
ssh -i ~/.ssh/id_rsa [e-mail]

# With verbose output for debugging
ssh -v [e-mail]

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

Credential Access

High

• Category: Privilege Escalation

Content

ssh [e-mail]

# With SSH key
ssh -i ~/.ssh/id_rsa [e-mail]

# With verbose output for debugging
ssh -v [e-mail]

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

External Script Fetching

High

• Category: Supply Chain

Content

## CLI Reference

The `aitun` command (installed via `pip install aitun`, or alternatively `curl -fsSL https://aitun.cc/install.sh | bash` / `irm https://aitun.cc/install.ps1 | iex` on Windows) accepts these flags:

| Flag | Description |
|---|---|

• Confidence: 97% confidence
• Finding: Repeating the pipe-to-shell install pattern in the CLI reference normalizes insecure software installation and increases the likelihood users will execute unverified remote code. This is especially risky in a skill that already deals with network exposure and privileged system setup.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill’s purpose is to expose a local SSH service to the public internet, but the description/front matter does not prominently warn users that this creates a remotely reachable login surface. In this context, omission of an upfront warning is dangerous because users may enable internet exposure without understanding risks like brute force attacks, credential compromise, or unintended access to an internal machine.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

```bash
# Ubuntu/Debian
sudo apt install openssh-server -y
sudo systemctl start sshd

# CentOS/RHEL

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

```bash
# Ubuntu/Debian
sudo apt install openssh-server -y
sudo systemctl start sshd

# CentOS/RHEL

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

```bash
# Ubuntu/Debian
sudo apt install openssh-server -y
sudo systemctl start sshd

# CentOS/RHEL

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

sudo systemctl start sshd

# CentOS/RHEL
sudo yum install openssh-server -y
sudo systemctl start sshd

# macOS (usually pre-installed)

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

sudo systemctl start sshd

# CentOS/RHEL
sudo yum install openssh-server -y
sudo systemctl start sshd

# macOS (usually pre-installed)

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The remote SSH examples show how to connect and run commands against the exposed host, but they do not directly warn that anyone with valid access can execute shell commands on the machine being exposed. Because this skill is specifically for remote shell access, the missing warning increases the chance that users expose sensitive systems without appreciating that they are granting command execution capability.

Intent-Code Divergence

Medium

• Confidence: 99% confidence
• Finding: The Python example explicitly disables TLS hostname verification and certificate validation with `check_hostname = False` and `verify_mode = ssl.CERT_NONE`. That permits man-in-the-middle interception of the outer TLS layer, undermining the claimed SSH-over-TLS security guarantees and exposing SSH sessions to traffic interception or redirection to an attacker-controlled endpoint.

Static analysis

No suspicious patterns detected.