Is asteinberger/portainer safe?
https://github.com/openclaw/skills/tree/main/skills/asteinberger/portainer
The asteinberger/portainer skill is a legitimate Docker infrastructure management tool with no malicious content in SKILL.md or portainer.sh, a clean install footprint, and confirmed canary integrity. The primary security concern is not malice but inherent capability: the skill grants an LLM agent full Portainer control-plane access including container lifecycle management and git-based stack redeployment, which represents significant blast radius if the agent is manipulated through other vectors. Users should install this skill only with full awareness that the agent will have the ability to disrupt services and trigger deployments.
Category Scores
Findings (8)
HIGH Docker control-plane fully exposed to LLM agent -20 ▶
The skill grants the agent the ability to start, stop, restart containers and trigger git-based stack redeployments across all Docker endpoints registered in Portainer. A manipulated agent could halt critical services or trigger deployment pipelines. The redeploy command in particular executes a full git pull and container rebuild cycle.
MEDIUM Container logs expose sensitive runtime data to agent context -15 ▶
The logs command fetches container stdout/stderr from Portainer and passes it through strings. Container logs frequently contain database connection strings, API keys, session tokens, and user data. This content becomes part of the LLM agent's context window and could be included in responses or subsequent tool calls.
MEDIUM Infrastructure enumeration via containers and stacks commands -5 ▶
The skill enables the agent to enumerate all Docker containers (names, states, uptime) and all Compose stacks (IDs, names, status, git repository URLs). This topology information could be used for targeted follow-up attacks if the agent is combined with network or file-access skills.
MEDIUM Unsafe env file sourcing pattern via xargs word-splitting -10 ▶
The script uses export $(grep -E '^PORTAINER_' "$ENV_FILE" | xargs) to load credentials. This pattern is vulnerable to word-splitting: env values containing spaces will be split into multiple arguments by xargs, potentially creating unexpected variable assignments or passing arguments to export. If ~/.clawdbot/.env is user-writable by an attacker, arbitrary variables could be injected.
LOW Unencoded user-controlled values interpolated into curl URLs -5 ▶
Variables $STACK_ID, $ENDPOINT, $CONTAINER_ID, and $TAIL are interpolated directly into curl URL strings without URL encoding or validation. While $CONTAINER_ID is derived from a prior API response (reducing attack surface), $STACK_ID and $ENDPOINT come from command-line arguments that an agent could supply with unexpected values.
LOW Hardcoded author-specific stack IDs in SKILL.md examples -5 ▶
SKILL.md embeds specific stack IDs (25, 33, 35, 4) and container names (steinbergerraum-web-1, cora-web-1, minecraft) from the author's personal infrastructure. While these fail safely in other environments, they subtly train the agent to target specific numeric IDs, which could cause confusion or misdirection if similar IDs exist in a different user's Portainer instance.
INFO Clean install — no unexpected files, processes, or connections 0 ▶
The clone fetched only the expected three files from GitHub via sparse checkout. No new listening services, no unexpected outbound connections, no writes outside the skill directory, and no post-install hooks were observed.
INFO Canary file accesses attributable to monitoring framework, not skill 0 ▶
Sensitive canary files were opened and read at two points (before clone and after install), but both access patterns match the oathe monitoring framework's setup and verification lifecycle. The skill's portainer.sh has no code path reaching these file paths. All files closed with CLOSE_NOWRITE; monitoring reports all canary files intact.