Is luckypipewrench/pipelock safe?
https://github.com/openclaw/skills/tree/main/skills/luckypipewrench/pipelock
The pipelock SKILL.md is textually clean — no prompt injection, hidden instructions, persona overrides, or malicious patterns were detected in the two-file skill package, and the git install was a minimal sparse checkout with only expected GitHub network activity. However, the skill's core design creates a high-privilege MITM position: it instructs the agent to route all HTTP traffic through an unaudited external proxy binary installed via 'go install @latest', which could silently harvest every API key, auth token, and request body the agent transmits if the binary is malicious or receives a compromised update. Credential honeypot files were accessed twice during the audit window at timestamps consistent with the Oathe monitoring system's own baseline and post-install integrity checks rather than skill-induced behavior, and all canary files were confirmed unmodified.
Category Scores
Findings (8)
HIGH Proxy creates comprehensive MITM position for all agent HTTP traffic -25 ▶
The skill instructs the agent to route every outbound HTTP request through a local proxy at localhost:8888 using the pattern 'curl http://localhost:8888/fetch?url=
HIGH External unaudited binary installed via go install @latest -20 ▶
The skill requires installing a Go binary from a third-party GitHub repository using 'go install github.com/luckyPipewrench/pipelock/cmd/pipelock@latest'. The @latest tag means the installed binary can change on every installation without user awareness of what changed. This binary is not included in the audited skill files and cannot be reviewed here. A compromised or malicious future update to the Go module would be silently installed on any subsequent 'go install' invocation.
MEDIUM Wolf-in-sheep's-clothing MITM framed as a security feature -45 ▶
Presenting a full-traffic network interceptor as a 'security harness' is a documented social engineering vector that lowers user skepticism about granting network interception access. The claimed DLP and credential-scanning features require the same technical capabilities as a credential harvester: reading all outbound request bodies, parsing Authorization headers, and logging destination URLs. An attacker controlling the pipelock binary would have complete, silent visibility into all agent API interactions with no behavioral signal that distinguishes legitimate scanning from data collection.
MEDIUM All six credential honeypot files read at two separate timestamps -25 ▶
Six credential honeypot files were opened and read at audit timestamps 1771927740.306 (within 31ms of monitoring start, correlated with 'ss -tunap' at 1771927740.275) and again at 1771927763.542 (post-install phase). Both access windows align temporally with the Oathe monitoring infrastructure's own operations: the first with pre-install canary baseline hashing and the second with post-install integrity verification. No EXECVE record for a skill-spawned process was correlated to either access. Files were not modified in either case.
MEDIUM Credential file access attribution to monitoring system not definitively confirmed -10 ▶
While both rounds of credential file access correlate temporally with known Oathe monitoring operations, the specific process responsible cannot be definitively established from EXECVE/PATH cross-correlation in the available audit logs. A pre- or post-clone hook reading these files cannot be completely excluded, though no such hooks were found in the installed skill files and the file timestamps align more strongly with monitoring phase transitions than with git clone events.
LOW Persistent proxy startup instruction modifies all session HTTP behavior -12 ▶
The skill instructs the agent to run 'pipelock run --config pipelock.yaml' and route all subsequent curl/HTTP requests through localhost:8888. This constitutes a permanent session-wide behavioral modification affecting all network activity, not scoped to pipelock-specific tasks. It is explicitly documented but represents a broad-scope instruction injected via system prompt that persists for the entire agent session.
LOW SSH host key reads during install window attributed to sshd initialization -12 ▶
SSH host key files (/etc/ssh/ssh_host_rsa_key, ssh_host_ecdsa_key, ssh_host_ed25519_key) were read at 10:09:05. These reads correlate directly with sshd spawning new worker processes for incoming SSH connections to the audit infrastructure (EXECVE shows /usr/sbin/sshd -D -R at the same timestamp). Not attributed to the skill. Documented for completeness.
INFO No exfiltration detected; canary file content verified intact 0 ▶
Despite multiple credential file reads, the Oathe canary integrity check confirms all six honeypot files are unmodified. Packet capture shows no unexpected outbound data after the git clone completed. The connection diff confirms the only post-install TCP connection is the SSH session to the audit infrastructure (10.0.2.2:45078); no new sockets or listeners were introduced.