tunneling

• Outcome: Review
• Latest audit: Sep 10, 2026 · 9:43 AM UTC
• Version: 1.0.0

Overview

This skill does what it says, but it can publish any local service to the public internet without enough warning, scoping, or shutdown guidance.

Review before installing. Use this only for non-sensitive local apps that are safe to make public, avoid exposing databases, admin consoles, debug ports, or services with secrets, and stop the SSH process as soon as sharing or testing is finished. Prefer adding authentication or access restrictions around anything exposed through the tunnel.

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 (2)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:20

Finding

Unauthenticated Public Exposure of Arbitrary Local Services

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 20-26 and 46-53
Vulnerability Type: Unrestricted reverse SSH tunnel exposing a local service publicly
Risk Level: High

Vulnerable Code Snippet:

markdown

Expose a local port to the internet:

```bash
ssh -o StrictHostKeyChecking=accept-new -R 80:localhost:<PORT> tinyfi.sh

Replace <PORT> with the port your app is running on. The command will print a public https://<random>.tinyfi.sh URL.

text

The operational instructions additionally state:

```markdown
## Usage Guidelines

When starting a tunnel for the user:

1. **Ask which port** to expose if not already specified
2. **Run the SSH command** in the background so the agent can continue working
3. **Report the public URL** back to the user once the tunnel is established
4. The tunnel stays open as long as the SSH connection is alive

Technical Analysis

The skill directs the agent to create a reverse SSH tunnel that makes an arbitrary local TCP service available through a public HTTPS URL. It does not require the agent to determine whether the selected port hosts a sensitive service, confirm that the application has access controls, restrict the public source addresses, or obtain explicit informed consent immediately before publication.

The tunnel is also intended to run in the background and remain available for the lifetime of the SSH connection. This increases the period during which an unintentionally exposed service can be accessed. Local development applications frequently contain debug interfaces, administrative functions, internal APIs, source maps, test credentials, or operations that assume requests originate from a trusted local system.

Attack Path

1. A user or agent selects a port containing a local development, administration, debug, or internal service.
2. The agent runs the documented reverse SSH command.
3. tinyfi.sh assigns ...[truncated 1170 chars]

Remediation

View remediation

Remediation Suggestions

• Require explicit confirmation that clearly identifies the local port, detected service, public hostname, expected duration, and unauthenticated-public-access risk.
• Inspect the target port before opening the tunnel and refuse known-sensitive services by default, including databases, SSH, remote desktop, container control sockets, debugging ports, and unauthenticated administration interfaces.
• Require application-level authentication before exposing a service. Prefer a tunneling provider that supports authenticated access, source-IP restrictions, or identity-aware access policies.
• Bind the forwarding target explicitly to 127.0.0.1 and verify that it is the intended service.
• Use a defined timeout instead of leaving the background process active indefinitely, and provide a command or process identifier for immediate termination.
• Record and report when the tunnel starts and stops so the user can verify that public exposure has ended.
• Warn users not to expose applications containing production data, secrets, debug consoles, or privileged administrative functions.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:22

Finding

Automatic Trust of an Unverified SSH Host Key on First Connection

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 22-23, 32-33, and 42-43
Vulnerability Type: Trust-on-first-use SSH host verification
Risk Level: Medium

Vulnerable Code Snippet:

bash

ssh -o StrictHostKeyChecking=accept-new -R 80:localhost:<PORT> tinyfi.sh

The same unsafe host-key policy is used in the custom-subdomain and keep-alive variants:

bash

ssh -o StrictHostKeyChecking=accept-new -R myname:80:localhost:<PORT> tinyfi.sh

bash

ssh -o StrictHostKeyChecking=accept-new -o ServerAliveInterval=60 -R 80:localhost:<PORT> tinyfi.sh

Technical Analysis

StrictHostKeyChecking=accept-new automatically stores and trusts a host key when no key for the hostname is already present. It protects against a changed key after initial enrollment, but it does not authenticate an unknown server during the first connection.

If DNS resolution or the network path is compromised during that initial connection, an attacker can present an attacker-controlled SSH host key. The client will accept and persist that key without comparing it to a trusted fingerprint. Subsequent connections may then continue trusting the attacker's endpoint.

Attack Path

1. The local environment has no existing trusted host-key entry for tinyfi.sh.
2. An attacker gains control over DNS resolution or can intercept the initial network connection.
3. The attacker redirects the SSH connection to an attacker-controlled SSH server.
4. The malicious server presents its own host key.
5. Because StrictHostKeyChecking=accept-new is enabled, the SSH client accepts and stores that key automatically.
6. The agent establishes the reverse forwarding session with the attacker-controlled endpoint.
7. The attacker can expose or relay traffic intended for the legitimate tunneling service and may continue receiving connections while the poisoned host-key entry remains trusted.

Impact Assess

...[truncated 547 chars]

Remediation

View remediation

Remediation Suggestions

• Obtain the legitimate service's SSH host-key fingerprints through a separately authenticated channel and document them in the skill.

• Provision a dedicated known_hosts file containing the verified key before opening the tunnel.

• Use strict verification with options such as:

  bash

  ssh \
    -o StrictHostKeyChecking=yes \
    -o UserKnownHostsFile=/path/to/dedicated_known_hosts \
    -R 80:localhost:<PORT> \
    tinyfi.sh
  

• Do not retrieve the fingerprint from the same unauthenticated network location immediately before connecting, because that would remain vulnerable to the same interception.

• If the provider rotates its host key, require authenticated verification of the new fingerprint before updating the trusted entry.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (2)

Missing User Warnings

High

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

Finding

The skill explicitly helps expose a local service to the public internet and emphasizes that it requires no signup or authentication, but it provides no warning about the security, privacy, or access-control consequences. This can lead users to unintentionally publish development servers, admin panels, webhook receivers, or other sensitive local services to unauthenticated internet traffic.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The instruction to run the SSH tunnel in the background encourages persistent operation while omitting that the service remains publicly exposed for as long as the SSH session stays alive. Users may believe the action is temporary or passive, resulting in longer-than-intended exposure of local applications to scanning, abuse, or unauthorized access.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.