Back to skill

Security audit

GitLab

Security checks for vulnerabilities and agentic risk

Overview

This is a static GitLab CI/CD tips skill with one incomplete Docker-in-Docker security warning, but it does not run code or request access itself.

Use the GitLab CI tips as reference material, but be careful with the Docker-in-Docker snippet: only use plaintext Docker port 2375 or disabled TLS inside an isolated, ephemeral CI job network, and prefer properly configured TLS or safer build approaches where possible.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:30
Finding

Insecure Plaintext Docker Daemon Configuration Guidance

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 30-31
Vulnerability Type: Unauthenticated plaintext Docker daemon access
Risk Level: High

Vulnerable Code Snippet:

markdown
- `DOCKER_HOST: tcp://docker:2375` required — job uses wrong Docker otherwise
- `DOCKER_TLS_CERTDIR: ""` or configure TLS properly — half-configured TLS breaks builds

Technical Analysis

The Skill recommends connecting to a Docker daemon over plaintext TCP port 2375 and presents disabling TLS as a normal configuration option. A Docker API exposed this way does not provide transport encryption or certificate-based client authentication.

If an attacker can reach the daemon endpoint, the attacker may issue Docker API requests to create containers, run arbitrary commands, access images and volumes, or mount resources available to the daemon. Because Docker-in-Docker daemons are frequently privileged, successful control may also create a path to the CI runner host. The guidance does not state that disabling TLS is acceptable only under strict network isolation, nor does it warn against publishing port 2375 beyond the isolated job network.

Attack Path

  1. A user follows the Skill guidance and configures DOCKER_HOST to use tcp://docker:2375.
  2. TLS is disabled by setting DOCKER_TLS_CERTDIR to an empty value.
  3. The Docker API becomes reachable from another workload, runner, or adjacent network due to insufficient service-network isolation or port exposure.
  4. An attacker connects to port 2375 without credentials or client certificates.
  5. The attacker invokes Docker API operations to launch attacker-controlled containers, inspect images or volumes, and access resources available to the daemon.
  6. If the daemon is privileged or exposes host resources, the attacker may pivot from daemon control to compromise of the runner host.

Impact Assessment

Exploitation can grant administrative control over the affect ...[truncated 338 chars]

Remediation
View remediation

Remediation Suggestions

  • Prefer a TLS-authenticated Docker daemon on port 2376 and require certificate verification and client authentication.
  • Do not recommend DOCKER_TLS_CERTDIR: "" without a prominent security warning and explicit constraints.
  • If plaintext Docker-in-Docker is unavoidable, limit it to an ephemeral, per-job network namespace that is inaccessible to other jobs, runners, and external networks.
  • Never publish port 2375 on a host or broadly reachable interface.
  • Apply firewall and network-policy rules so that only the intended job container can reach the Docker service.
  • Use dedicated, disposable runners and avoid mounting the host Docker socket or sensitive host paths.
  • Prefer rootless or daemonless build systems where feasible, and apply least-privilege controls to the build environment.
  • Add guidance for validating network isolation and daemon exposure before enabling plaintext access.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.