Localhost Bridge

• Outcome: Review
• Latest audit: Sep 11, 2026 · 1:00 AM UTC
• Version: 2.0.0

Overview

The skill is transparent about its purpose, but it guides users to create a persistent privileged network bridge that can expose host-local services to containers.

Install only if an administrator intentionally wants containers on a specific Docker network to reach a specific localhost service. Review the generated systemd unit and UFW rule before running them, confirm the service has its own authentication, test that the port is not publicly reachable, and plan cleanup commands before enabling persistence.

A.I.G

Vulnerability Patterns

• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• 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 (1)

T06 · System Persistence

Error

• Location: SKILL.md:68

Finding

Persistent Privileged Network Bridge Exposes Host-Local Services to Containers

Content

View full analysis

--.service > /dev/null << 'EOF' [Unit] Description=Socat bridge: -> : After=network.target docker.service [Service] Type=simple ExecStart=/usr/bin/socat TCP-LISTEN:,bind=,fork,reuseaddr TCP:127.0.0.1: Restart=always RestartSec=5 [Install] WantedBy=multi-user.target EOF # Review the file before enabling: cat /etc/systemd/system/socat---.service sudo systemctl daemon-reload sudo systemctl enable --now socat--- ``` ### Technical Analysis The instructions use root privileges to write a systemd unit under `/etc/systemd/system`, configure it with `Restart=always`, associate it with `multi-user.target`, and enable it immediately. Consequently, the network relay starts automatically after reboot and survives the individual Skill run. The relay forwards connections received on a Docker bridge gateway address to a service bound to host loopback. This deliberately crosses the isolation boundary that normally prevents containers from accessing services restricted to `127.0.0.1`. Although this behavior is disclosed and supports the declared bridge functionality, persistent startup registration is a high-impact host modification and is not necessary for one-time or temporary connectivity. Binding to a bridge IP reduces exposure compared with binding to `0.0.0.0`, but it does not establish per-container authorization. Any container or process able to reach the selected bridge and pass applicable firewall rules may access the forwarded service. Incorrect substitution of the gateway, network, or port placeholders may broaden the exposure. ### Attack Path ...[truncated 1885 chars]

Remediation

View remediation

-- sudo rm /etc/systemd/system/socat---.service sudo systemctl daemon-reload sudo systemctl reset-failed sudo ufw delete allow in on br- to any port proto tcp ``` 8. **Continuously verify exposure.** Test from an intended container, an unrela ...[truncated 413 chars]

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Rogue Agent: Self-Modification, Session Persistence
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration

Findings (9)

External Script Fetching

High

• Category: Supply Chain
• Confidence: 90% confidence

Finding

Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.

Content

Scanner excerpt · SKILL.md (reported line 29)May include surrounding context.

md

**Before running any command:**
1. Review the generated `/etc/systemd/system/socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-<PORT>.service` file — confirm `ExecStart` binds only to the intended Docker bridge IP (172.x.x.1), never 0.0.0.0
2. Review the UFW rule — confirm it targets the correct `br-<ID>` interface and port
3. After setup, verify the port is NOT reachable from the public network: `curl --connect-timeout 2 http://<PUBLIC_IP>:<PORT>/` must fail
4. Test from inside a container before deploying widely

**Do not grant an automated agent permissions to run these commands without human approval.**

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 70% confidence

Finding

Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Content

Scanner excerpt · SKILL.md (reported line 10)May include surrounding context.

md

always: false
privileged: false
requires:
  - sudo access (systemd service creation, UFW rules)
  - Docker daemon access (docker inspect, docker network inspect)
  - socat package (apt install socat)
---

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 89% confidence

Finding

This command writes a persistent systemd unit into /etc/systemd/system using sudo, creating a host-level service that forwards traffic from a Docker bridge to 127.0.0.1. Although the stated purpose is legitimate, any agent or operator applying unvalidated placeholders could expose sensitive localhost-only services or create unintended privileged persistence on the host.

Content

Scanner excerpt · SKILL.md (reported line 69)May include surrounding context.

Review the ExecStart line before enabling — confirm it binds to the Docker bridge IP only.

bash

sudo tee /etc/systemd/system/socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-<PORT>.service > /dev/null << 'EOF'
[Unit]
Description=Socat bridge: <SOURCE_NETWORK> -> <TARGET_SERVICE>:<PORT>
After=network.target docker.service

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 87% confidence

Finding

Reloading systemd with sudo activates newly dropped unit definitions and prepares the host to run a new persistent service. In the context of a skill, this is dangerous because it operationalizes privileged host changes and can cement an unsafe or misconfigured bridge if executed without strict human review.

Content

Scanner excerpt · SKILL.md (reported line 87)May include surrounding context.

Review the file before enabling:

cat /etc/systemd/system/socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-.service

sudo systemctl daemon-reload sudo systemctl enable --now socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-

text

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 93% confidence

Finding

Enabling and starting the service creates persistence across reboots and immediately opens a forwarding path to a localhost-bound host service. Even with benign intent, this materially increases attack surface by making internal services reachable from containers and establishing durable host-level behavior.

Content

Scanner excerpt · SKILL.md (reported line 88)May include surrounding context.

cat /etc/systemd/system/socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-.service

sudo systemctl daemon-reload sudo systemctl enable --now socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-

text

### 3. Add firewall rule (MANDATORY)

Session Persistence

Medium

• Category: Rogue Agent
• Confidence: 95% confidence

Finding

systemctl enable --now establishes persistence and immediately launches the bridge service, which is a classic form of durable system modification. In this context the persistence is documented, but it still increases risk because it survives reboot and can continue exposing localhost services long after the original task ends.

Content

Scanner excerpt · SKILL.md (reported line 88)May include surrounding context.

cat /etc/systemd/system/socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-.service

sudo systemctl daemon-reload sudo systemctl enable --now socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-

text

### 3. Add firewall rule (MANDATORY)

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 90% confidence

Finding

This sudo UFW command changes host firewall policy to permit inbound access on a Docker bridge interface to a specified port. While scoped more narrowly than a global allow rule, a mistaken bridge ID or port can expose sensitive services to unintended containers and weaken host network isolation.

Content

Scanner excerpt · SKILL.md (reported line 105)May include surrounding context.

ip link show br-${BRIDGE_ID}

Allow traffic only on that bridge interface

sudo ufw allow in on br-${BRIDGE_ID} to any port proto tcp comment "<SOURCE_NETWORK>-<TARGET_SERVICE>-"

text

### 4. Verify security

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 70% confidence

Finding

Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Content

Scanner excerpt · SKILL.md (reported line 156)May include surrounding context.

Install socat from your distro's official package repository:

bash

sudo apt-get install -y socat  # Debian/Ubuntu
sudo dnf install -y socat      # Fedora/RHEL

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 70% confidence

Finding

Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Content

Scanner excerpt · SKILL.md (reported line 157)May include surrounding context.

Install socat from your distro's official package repository:

bash

sudo apt-get install -y socat  # Debian/Ubuntu
sudo dnf install -y socat      # Fedora/RHEL

Static analysis

No suspicious patterns detected.