Proxy Manager

• Outcome: Review
• Latest audit: Sep 16, 2026 · 8:15 AM UTC
• Version: 1.0.2

Overview

This skill is a disclosed local Docker proxy manager, but it gives a third-party proxy container access to the host Docker socket, which is powerful enough to warrant careful review.

Install only on a trusted local development machine where you are comfortable giving the proxy container access to Docker. Prefer a safer design using a restricted docker-socket-proxy or explicit static routing, pin the container image by digest, and stop the proxy when it is not needed.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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

Findings (2)

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: docker-compose.yml:7

Finding

Direct Docker Socket Access Enables Host Privilege Escalation

Content

View full analysis

Vulnerability Details

File Location: docker-compose.yml, lines 7-10
Vulnerability Type: Excessive Docker daemon privileges
Risk Level: High

Vulnerable Code

yaml

    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - proxy-data:/etc/nginx/conf.d

Technical Analysis

The nginx-proxy container receives direct access to the host Docker daemon through /var/run/docker.sock. Although the socket is mounted with the :ro option, this only makes the socket filesystem entry read-only; it does not restrict the Docker API operations that can be submitted through an already opened Unix socket.

A process inside the container may therefore be able to invoke write-capable Docker API endpoints. If the proxy process, image, or one of its dependencies is compromised, an attacker could request the creation of a privileged container, mount the host filesystem, access other containers, or execute commands in containers managed by the daemon.

The socket is legitimately used for automatic container discovery, but unrestricted access to the complete Docker API violates least privilege and creates a container-to-host privilege-escalation boundary.

Attack Path

1. An attacker compromises the nginx-proxy process, its container image, or a component running inside the container.
2. The attacker opens /tmp/docker.sock from inside the compromised container.
3. The attacker submits a Docker API request to create a new container with elevated privileges and a bind mount of the host root filesystem.
4. The attacker starts that container through the Docker API.
5. The attacker accesses or modifies host files through the mounted filesystem, extracts secrets from other containers, or establishes effective root-level control of the Docker host.

Impact Assessment

Successful exploitation could provide effective root-equivalent control over the Docker host. The attacker could:

• Read or modify host files.
• Create privileged containers ...[truncated 394 chars]

Remediation

View remediation

Remediation Suggestions

1. Replace direct Docker socket mounting with a dedicated Docker socket proxy.
2. Configure the socket proxy to expose only the read-only API endpoints required for nginx-proxy container discovery, such as narrowly scoped container, network, and event inspection endpoints.
3. Explicitly deny container creation, start, exec, image-management, volume-management, secret-management, and other write-capable endpoints.
4. Place the socket proxy on an isolated internal Docker network that is reachable only by nginx-proxy.
5. Do not expose the socket proxy over a host port or any externally reachable interface.
6. Apply additional container hardening where compatible:
   • Run with a read-only root filesystem.
   • Drop unnecessary Linux capabilities.
   • Enable no-new-privileges.
   • Apply restrictive seccomp and AppArmor or SELinux policies.
7. Document that the :ro mount option does not make the Docker API read-only.
8. Monitor Docker daemon events for unexpected container creation, privileged containers, host bind mounts, and exec operations.

T08 · Insecure Dependencies

Warning

• Location: docker-compose.yml:3

Finding

Privileged Third-Party Container Image Is Not Pinned to an Immutable Digest

Content

View full analysis

Vulnerability Details

File Location: docker-compose.yml, line 3
Vulnerability Type: Mutable third-party dependency reference
Risk Level: Medium

Vulnerable Code

yaml

    image: jwilder/nginx-proxy:1.3.1

Technical Analysis

The container image is pinned to a version tag but not to an immutable content digest. Registry tags can be reassigned to different image content. Consequently, separate installations or later pulls of jwilder/nginx-proxy:1.3.1 are not guaranteed to execute the same artifact that was originally reviewed.

This supply-chain weakness is particularly significant because the image receives direct access to the Docker socket. If a publisher account, registry, build pipeline, or tag is compromised, substituted code would start with access to the Docker daemon and could use that access to escalate to the host.

The audit found no evidence that the currently referenced image is malicious. The risk arises from the lack of immutable artifact verification.

Attack Path

1. An attacker compromises the image publisher, registry account, distribution infrastructure, or build pipeline.
2. The attacker replaces or reassigns the 1.3.1 tag to an image containing malicious code.
3. A user deploys the Skill on a new host or pulls the tag again.
4. Docker starts the substituted image and mounts /var/run/docker.sock into it.
5. The malicious image submits privileged Docker API requests.
6. The attacker accesses other containers or creates a privileged container to compromise the host.

Impact Assessment

A successful supply-chain substitution could execute attacker-controlled code within the proxy container. Due to the Docker socket mount, the practical impact may extend beyond that container and include:

• Effective root-equivalent control of the Docker host.
• Unauthorized access to other containers and their secrets.
• Modification or destruction of containerized workloads and data.
• Creation of privileged conta ...[truncated 191 chars]

Remediation

View remediation

Remediation Suggestions

1. Pin the reviewed image to an immutable SHA-256 digest while retaining the version tag for readability:

yaml

    image: jwilder/nginx-proxy:1.3.1@sha256:<verified-digest>

2. Obtain the digest from a trusted registry and verify it independently before deployment.
3. Use image-signature and provenance verification where supported, and enforce verification in deployment policy.
4. Scan the exact digest for known vulnerabilities before approval.
5. Introduce a controlled update process in which digest changes require review, testing, and explicit approval.
6. Prefer actively maintained images from trusted publishers and periodically reassess whether the selected image remains supported.
7. Combine immutable pinning with restricted Docker API access so that compromise of the dependency does not automatically grant control of the host.

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (5)

Docker Socket Access

High

• Category: Privilege Escalation
• Confidence: 96% confidence

Finding

The skill explicitly documents mounting /var/run/docker.sock into the proxy container, which gives the container visibility into Docker daemon state and, in practice, often becomes a high-risk trust boundary break if the container or image is compromised. Even though the mount is read-only and justified for auto-discovery, exposing the Docker socket is a well-known dangerous pattern because it grants powerful insight and can facilitate container-to-host escalation depending on the daemon/API surface and surrounding environment.

Content

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

md

## Security Notes

- **Docker socket**: The proxy mounts `/var/run/docker.sock:ro` to auto-discover containers. This is required for VIRTUAL_HOST routing but grants the container read access to Docker daemon state. Only run on trusted development machines.
- **Port 80**: Bound to `127.0.0.1` — routes are reachable from the host only, not from other machines on the network.
- **Image provenance**: Pinned to `jwilder/nginx-proxy:1.3.1`. Review image updates before pulling a newer tag.

Docker Socket Access

High

• Category: Privilege Escalation
• Confidence: 98% confidence

Finding

Mounting /var/run/docker.sock into a container gives processes in that container direct access to the host Docker API. Even when mounted read-only at the filesystem level, the Docker UNIX socket still permits privileged API operations, so compromise of nginx-proxy or unsafe template parsing could let an attacker control other containers or potentially the host. In this skill's context, the proxy is explicitly designed to auto-discover other containers, which makes the socket access functional but also increases blast radius across the shared environment.

Content

Scanner excerpt · docker-compose.yml (reported line 9)May include surrounding context.

yaml

ports:
      - "127.0.0.1:80:80"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - proxy-data:/etc/nginx/conf.d
    networks:
      - codai_net

Shadow Command Trigger

Medium

• Category: Trigger Abuse
• Confidence: 70% confidence

Finding

Shadow Command Trigger: 'start proxy' conflicts with built-in command 'start'

Content

No source excerpt is available for this finding.

Shadow Command Trigger

Medium

• Category: Trigger Abuse
• Confidence: 70% confidence

Finding

Shadow Command Trigger: 'stop proxy' conflicts with built-in command 'stop'

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

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

Finding

The script's descriptive comments and usage/help text are written entirely in Portuguese, and runtime messages throughout the file also assume Portuguese output. Under the policy, forcing a specific language without user opt-in is a natural-language locale violation unless the constraint is explicitly justified as region-specific.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.