Is cprice70/shipstation-orders safe?
https://github.com/openclaw/skills/tree/main/skills/cprice70/shipstation-orders
The shipstation-orders skill is a legitimate e-commerce order monitoring tool with clean, auditable code and no evidence of malicious behavior. The installation was clean with no unexpected network connections, no canary file compromise, and no prompt injection content in SKILL.md. The primary concerns are operational rather than malicious: customer PII (names, order data, marketplace distribution) flows continuously through agent context via the heartbeat pattern, ShipStation API response content could serve as an indirect injection vector for actors with account access, and the persistent heartbeat execution creates an ongoing exposure surface. The skill is appropriate for its stated use case but should be reviewed for data handling policies before deployment in regulated environments.
Category Scores
Findings (8)
LOW Indirect prompt injection via ShipStation order data -10 ▶
The skill fetches orders from the ShipStation API and relays customer-supplied fields (order numbers, customer names, marketplace sources, shipping service names) directly into agent context via sessions_send. Any party able to create orders in the connected ShipStation account could craft field values to attempt prompt injection against the hosting agent.
MEDIUM Customer PII processed and relayed to agent context -15 ▶
The skill processes live e-commerce order data including customer names, order totals, marketplace identifiers (Amazon, Etsy, Shopify, TikTok), shipping service codes, and order timestamps. This data is pushed to the agent session via sessions_send on every heartbeat cycle. While this is the intended functionality, it means PII is continuously flowing through the agent's working context and any logs thereof.
LOW API credentials required and stored in plaintext .env -10 ▶
The skill requires SHIPSTATION_API_KEY and SHIPSTATION_API_SECRET to be stored in a plaintext .env file co-located with the skill scripts. check-orders.js reads this with readFileSync without error handling, crashing if absent. check-shipping.js handles absence gracefully. Credentials are base64-encoded (not encrypted) in the Authorization header per ShipStation V1 Basic Auth.
LOW Agent instructed to execute JavaScript via exec() on a schedule -15 ▶
SKILL.md heartbeat instructions tell the agent to call exec('node check-orders.js', ...) every 15 minutes. This creates a persistent code execution pattern within the agent loop. The code itself is clean and auditable, but the pattern establishes a recurring shell invocation from agent context.
LOW Runtime JavaScript execution with no sandboxing -5 ▶
Both check-orders.js and check-shipping.js are full Node.js scripts with access to fs, path, and fetch. They are invoked directly by node with no sandboxing. The code is well-scoped and readable, but executes with the full privileges of the agent process.
INFO Clean install from GitHub monorepo 0 ▶
Sparse checkout from the openclaw/skills monorepo targeting only the shipstation-orders subpath. No unexpected network connections during install. GitHub IP 140.82.121.4 is the only novel outbound connection; pre-existing Ubuntu connections were present before install.
INFO Canary file reads attributable to audit infrastructure only 0 ▶
Sensitive files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, gcloud credentials) were read at audit timestamps 1771924846 and 1771924863. The first batch correlates with sudo/oathe session initialization; the second with the canary integrity verification sweep. No node process executed skill code during the audit.
MEDIUM Persistent heartbeat creates continuous PII exposure window -30 ▶
The recommended deployment pattern runs check-orders.js every 15 minutes indefinitely. Each cycle fetches and surfaces customer order data into agent context. Over time this accumulates significant exposure of business-sensitive PII (customer names, order volumes, marketplace distribution) in agent logs and session history.