Back to skill

Security audit

Localhost Bridge

Security checks for vulnerabilities and agentic risk

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.

Vulnerability Patterns
  • System PersistenceInstalls backdoors, hooks, services, or scheduled tasks that survive the run
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips 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<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 68–88 **Vulnerability Type**: Persistent systemd service with host-level network access **Risk Level**: High ### Vulnerable Code ```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 [Service] Type=simple ExecStart=/usr/bin/socat TCP-LISTEN:<PORT>,bind=<GATEWAY_IP>,fork,reuseaddr TCP:127.0.0.1:<PORT> Restart=always RestartSec=5 [Install] WantedBy=multi-user.target EOF # Review the file before enabling: cat /etc/systemd/system/socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-<PORT>.service sudo systemctl daemon-reload sudo systemctl enable --now socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-<PORT> ``` ### 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
<![CDATA[ ## Remediation Suggestions 1. **Default to nonpersistent operation.** Provide a foreground or manually started `socat` command for temporary use. Make persistent systemd installation an explicit, separately approved option. 2. **Require service-layer authentication.** Do not treat Docker bridge isolation or UFW rules as the sole access-control mechanism. Configure authentication and, where appropriate, TLS on the target service. 3. **Apply strict input validation.** Validate the gateway as an expected private Docker bridge address, require numeric ports in the valid range, and restrict service and network names to safe systemd-compatible characters before writing a unit file. 4. **Restrict network access precisely.** Limit firewall access by bridge interface and expected source subnet. Verify the interface belongs to the intended Docker network before applying the rule. 5. **Harden the systemd unit.** Where compatible with `socat`, add controls such as: ```ini NoNewPrivileges=yes PrivateTmp=yes ProtectSystem=strict ProtectHome=yes ProtectKernelTunables=yes ProtectKernelModules=yes ProtectControlGroups=yes RestrictSUIDSGID=yes RestrictAddressFamilies=AF_INET AF_INET6 CapabilityBoundingSet= AmbientCapabilities= ``` 6. **Use explicit startup dependencies.** Replace or supplement `After=docker.service` with appropriate network-online and Docker requirements so that failures do not cause an uncontrolled restart loop. 7. **Document complete teardown procedures.** Include commands to stop and disable the service, delete the unit, reload systemd, and remove the exact firewall rule: ```bash sudo systemctl disable --now socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-<PORT> sudo rm /etc/systemd/system/socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-<PORT>.service sudo systemctl daemon-reload sudo systemctl reset-failed sudo ufw delete allow in on br-<BRIDGE_ID> to any port <PORT> proto tcp ``` 8. **Continuously verify exposure.** Test from an intended container, an unrela ...[truncated 413 chars]
Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Rogue AgentSelf-Modification, Session Persistence
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Findings (9)

External Script Fetching

High
Category
Supply Chain
Content
**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.**
Confidence
90% confidence
Finding
Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
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)
---
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
**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
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.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
# Review the file before enabling:
cat /etc/systemd/system/socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-<PORT>.service

sudo systemctl daemon-reload
sudo systemctl enable --now socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-<PORT>
```
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.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
cat /etc/systemd/system/socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-<PORT>.service

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

### 3. Add firewall rule (MANDATORY)
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.

Session Persistence

Medium
Category
Rogue Agent
Content
cat /etc/systemd/system/socat-<SOURCE_NETWORK>-<TARGET_SERVICE>-<PORT>.service

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

### 3. Add firewall rule (MANDATORY)
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.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
ip link show br-${BRIDGE_ID}

# Allow traffic only on that bridge interface
sudo ufw allow in on br-${BRIDGE_ID} to any port <PORT> proto tcp comment "<SOURCE_NETWORK>-<TARGET_SERVICE>-<PORT>"
```

### 4. Verify security
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.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
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
```
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
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
```
Confidence
70% confidence
Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Static analysis

No suspicious patterns detected.