Security audit
Security checks for vulnerabilities and agentic risk
This skill is mostly a Docker sandbox usage guide, but it overstates safety for untrusted code while documenting high-impact sandbox capabilities without enough warning.
Review this skill before installing if you plan to use it for hostile or truly untrusted code. Confirm whether /run/docker.sock is isolated inside the sandbox VM or connected to the host Docker daemon, assume mounted workspaces can be modified by code in the sandbox, use deny-by-default network rules, and avoid docker sandbox reset unless you are prepared to lose sandbox state.
The skill repeatedly markets the environment as safe for running untrusted code, but the same document later states the sandbox exposes the host Docker socket. Access to the host Docker daemon is effectively equivalent to privileged control over the host/container environment, so the isolation claim is materially misleading and can lead users to run hostile code under a false sense of safety.
Providing /run/docker.sock inside a sandbox for 'untrusted code' allows code in the sandbox to control the host Docker daemon, start privileged containers, mount host filesystems, or escape intended restrictions. In this skill's context, that directly undermines the core security boundary the sandbox is supposed to provide.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
Node.js fetch doesn't use the proxy. Use the proxy-fix.js require hook above, or use curl instead:
docker sandbox exec my-sandbox curl -sL https://api.example.com/data
The documented docker sandbox reset command is destructive and the note only says it 'clears all sandbox state' without a strong warning before use. Users following troubleshooting steps may unintentionally destroy environments or data they expected to preserve.
No suspicious patterns detected.