Back to skill

Security audit

Dockerlabs

Security checks for vulnerabilities and agentic risk

Overview

Dockerlabs is a local Docker-themed logging tool, but it is presented partly as a Docker tutorial and validation toolkit, which can lead users to store sensitive troubleshooting data without enough safeguards.

Review before installing. Use it only as a local note/audit logger, not as a real Docker validator, generator, linter, or fixer. Do not paste secrets, registry tokens, private keys, production compose files, or sensitive incident details unless you are comfortable with them being stored in plaintext under ~/.local/share/dockerlabs and later searchable/exportable.

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

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/script.sh:6
Finding
Plaintext Activity Logs Are Created Without Explicit Restrictive Permissions<![CDATA[ ## Vulnerability Details **File Location**: `scripts/script.sh:6-9`; representative log write at `scripts/script.sh:125-133`, with equivalent behavior in all activity-recording command branches **Vulnerability Type**: Sensitive data exposure through insecure file permissions and plaintext logging **Risk Level**: Medium ### Vulnerable Code ```bash DATA_DIR="${HOME}/.local/share/dockerlabs" mkdir -p "$DATA_DIR" _log() { echo "$(date '+%m-%d %H:%M') $1: $2" >> "$DATA_DIR/history.log"; } ``` Representative command branch: ```bash check) shift if [ $# -eq 0 ]; then echo "Recent check entries:" tail -20 "$DATA_DIR/check.log" 2>/dev/null || echo " No entries yet. Use: dockerlabs check <input>" else local input="$*" local ts=$(date '+%Y-%m-%d %H:%M') echo "$ts|$input" >> "$DATA_DIR/check.log" local total=$(wc -l < "$DATA_DIR/check.log") echo " [Dockerlabs] check: $input" echo " Saved. Total check entries: $total" _log "check" "$input" fi ``` ### Technical Analysis The script persistently records arbitrary user-supplied text in per-command log files and duplicates the text in `history.log`. These files are stored as plaintext under `~/.local/share/dockerlabs`. Neither the data directory nor the log files receive explicit restrictive permissions. Their resulting modes are controlled by the environment's existing directories and process `umask`. In an environment with a permissive `umask` or inadequately protected parent directory, another local account or process may be able to read the logs. The skill is intended for Docker troubleshooting and configuration workflows. Inputs in that context may contain registry credentials, access tokens, private image locations, environment variables, internal hostnames, deployment details, or copied configuration fragments. The script does not warn against submitting secrets and performs no redaction. The same issue affects ...[truncated 1249 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Set a restrictive file-creation mask before creating any persistent data: ```bash umask 077 ``` 2. Create and verify the directory with owner-only permissions: ```bash install -d -m 700 "$DATA_DIR" chmod 700 "$DATA_DIR" ``` 3. Create log files explicitly with mode `600` before appending to them: ```bash install -m 600 /dev/null "$DATA_DIR/history.log" ``` Use equivalent guarded creation for each command-specific log and avoid truncating existing files. 4. Validate that the data directory is owned by the current user and is not a symbolic link before writing to it. 5. Warn users that supplied input is retained persistently and must not include passwords, tokens, private keys, or other secrets. 6. Add configurable secret redaction for common credential formats and provide retention and secure-deletion controls. 7. Avoid duplicating full sensitive values in both the command-specific log and `history.log`; record only minimal metadata in the unified history. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/script.sh:72
Finding
CSV Export Allows Spreadsheet Formula Injection<![CDATA[ ## Vulnerability Details **File Location**: `scripts/script.sh:72-78` **Vulnerability Type**: CSV injection through unescaped user-controlled fields **Risk Level**: Medium ### Vulnerable Code ```bash csv) echo "type,time,value" > "$out" for f in "$DATA_DIR"/*.log; do [ -f "$f" ] || continue local name=$(basename "$f" .log) while IFS='|' read -r ts val; do echo "$name,$ts,$val" >> "$out"; done < "$f" done ;; ``` ### Technical Analysis The CSV exporter writes the user-controlled `val` field directly into a comma-separated record. It does not: - Quote fields containing commas, quotes, or line breaks. - Escape embedded double quotes. - Neutralize values beginning with spreadsheet formula markers such as `=`, `+`, `-`, or `@`. - Use a standards-compliant CSV encoder. An attacker who can influence an activity entry can submit a value beginning with a spreadsheet formula. When the resulting export is opened in formula-capable spreadsheet software, the application may interpret that value as a formula rather than as text. Spreadsheet protections differ by product and configuration, so formula execution is not guaranteed. However, unsafe formulas may initiate external network requests, misrepresent exported data, or invoke other spreadsheet-supported functionality. Ordinary delimiters and line breaks can also corrupt the CSV structure and inject additional rows or columns. ### Attack Path 1. An attacker persuades a user to record attacker-controlled text or otherwise controls an argument passed to an activity-recording command. 2. The text begins with a spreadsheet formula marker, for example a value designed to trigger an external lookup. 3. The value is stored in a command log without normalization. 4. The user runs `dockerlabs export csv`. 5. The exporter copies the value directly into `export.csv`. 6. The user opens the exported file in spreadsheet software. 7. If the spreadsheet application evaluates impor ...[truncated 704 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace manual string concatenation with a standards-compliant CSV encoder. 2. Enclose every field in double quotes and replace each embedded double quote with two double quotes. 3. Normalize line breaks so that untrusted input cannot create unintended records. 4. Before encoding, neutralize fields whose first non-whitespace character is `=`, `+`, `-`, or `@`. A common defensive approach is to prefix such values with an apostrophe, while documenting that transformation. 5. Treat tabs, carriage returns, and other characters recognized by spreadsheet applications as potentially unsafe prefixes. 6. Add tests covering commas, quotes, multiline input, Unicode, and formula-like payloads. 7. Where exact value preservation is required, prefer JSON export and ensure that export also uses a real JSON encoder rather than manual interpolation. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (9)

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The skill is marketed as a Docker learning/tutorial tool, but its documented behavior is primarily a persistent local logging system for arbitrary user inputs. This mismatch can mislead users into providing operational details, credentials, or internal configuration data under the assumption they are using a harmless study tool, resulting in unexpected retention and later disclosure through search/export features.

Description-Behavior Mismatch

High
Confidence
98% confidence
Finding
The advertised skill purpose is Docker learning and orchestration practice, but the implemented functionality is a generic local data logger and reporting utility. This mismatch is dangerous because users may invoke the skill expecting Docker-scoped behavior while unknowingly supplying arbitrary text that is retained locally and later exportable, creating an opportunity for unnecessary collection of sensitive prompts, commands, or secrets.

Description-Behavior Mismatch

High
Confidence
99% confidence
Finding
The command set uses Docker-themed names such as check, validate, generate, and preview, but every branch simply stores user-provided text into local log files instead of performing Docker operations. This deceptive scope expansion can capture sensitive content users paste into the tool under a false expectation of domain-specific processing, making the manifest mismatch materially security-relevant.

Description-Behavior Mismatch

Medium
Confidence
96% confidence
Finding
The manifest claims a hands-on Docker tutorial/study skill, but the documented commands act as a generic audit/logging CLI rather than an educational Docker workflow. This deceptive framing increases the chance that users will enter sensitive environment details or troubleshooting content that gets persistently stored without clear expectation.

Intent-Code Divergence

Medium
Confidence
93% confidence
Finding
The tool advertises active Docker operations such as check, validate, generate, lint, preview, fix, and report, but the documented semantics show these commands mostly append text to logs or show prior entries. Users may rely on nonexistent validation or remediation, creating a false sense of security while simultaneously storing sensitive troubleshooting data locally.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The skill explicitly logs all command inputs locally and supports export/search over accumulated records, but it does not provide a strong warning about privacy, retention, or the risk of entering secrets. In Docker contexts, inputs often contain image URLs, registry tokens, internal hostnames, compose snippets, or incident notes, so silent persistence materially increases exposure risk.

Intent-Code Divergence

Medium
Confidence
84% confidence
Finding
The file header describes the script generically as a 'devtools tool', and the help banner repeats 'devtools toolkit'. That documented intent conflicts with the manifest's narrower claim that this skill is for learning Docker hands-on with tutorials on containers and orchestration.

Context-Inappropriate Capability

Medium
Confidence
90% confidence
Finding
The export, search, stats, recent, and status functions provide broad local data discovery and extraction capabilities that are not justified by the stated Docker tutorial use case. While not directly exfiltrating data off-host, these features increase the blast radius of any sensitive information entered into the tool by making it easy to aggregate, enumerate, and reformat retained content.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
User-provided input is appended to persistent files under ~/.local/share/dockerlabs without any upfront warning, consent flow, retention limit, or sensitivity guidance. In the context of a misleading Docker-themed skill, users may paste commands, credentials, environment snippets, or internal notes, causing silent local data retention that can later be exposed through export or local access.

Static analysis

No suspicious patterns detected.